* Re: Deleting remote branch pointed by remote HEAD
From: Sitaram Chamarty @ 2009-01-21 14:52 UTC (permalink / raw)
To: git
In-Reply-To: <e29894ca0901210502n1ed1187bm46669a402ab4fe48@mail.gmail.com>
On 2009-01-21, Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
> I deleted a remote branch which was pointed by HEAD, this way: "git
> push origin :master"
>
> Then for almost every git command, I get this error: "error:
> refs/remotes/origin/HEAD points nowhere!".
>
> I found this situation non-friendly. Fortunately, I could understand
> what's going on. But a new user might be confused.
That's a pretty advanced command for a beginner. I have
people who're only using the GUI (in the presumption that it
will be less confusing or less powerful or whatever) and
have managed to right click on a remote branch, choose
"checkout this branch" and have made commits on it without
knowing they're not on any branch!
I wish I had your problem :-)
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Michael J Gruber @ 2009-01-21 15:24 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: Michael J Gruber, git
In-Reply-To: <e29894ca0901210638t636de791sf27d28893a7a0b65@mail.gmail.com>
Marc-André Lureau venit, vidit, dixit 21.01.2009 15:38:
> On Wed, Jan 21, 2009 at 4:33 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Marc-André Lureau venit, vidit, dixit 21.01.2009 14:02:
>>> Hi
>>>
>>> I deleted a remote branch which was pointed by HEAD, this way: "git
>>> push origin :master"
>>>
>>> Then for almost every git command, I get this error: "error:
>>> refs/remotes/origin/HEAD points nowhere!".
>> You're talking about about the remote git repo, aren't you?
>>
>
> Sure. But the error is on the local repo.
So, you get these errors on the local repo when dealing with the remote
repo, right? I guess this means two things:
1) You are deleting a remote branch
2) Your original report could have been a bit more detailed ;)
In fact, I'm still unsure about your setup and can't reproduce, unless
"almost every git command" was vastly exaggerated, and Adeodato's
description matches your setup. Does it?
If yes then git has basically no choice, unless you want git to leave
HEAD in place as a detached head. This is related to how the symref is
resolved, which in turn is related to the issue of removing remote
branches, which in turn is related to an issue I've been meaning to look
into quite a while ago... So, reproducibility would be nice.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] Change the spelling of "wordregex".
From: Boyd Stephen Smith Jr. @ 2009-01-21 15:33 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Santi Béjar, Thomas Rast, git, Junio C Hamano, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901210925430.7929@racer>
[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]
On Wednesday 21 January 2009, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote about 'Re: [PATCH] Change the spelling
of "wordregex".':
>On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
>> diff --git a/userdiff.c b/userdiff.c
>> index 2b55509..d556da9 100644
>> --- a/userdiff.c
>> +++ b/userdiff.c
>> @@ -6,8 +6,8 @@ static struct userdiff_driver *drivers;
>> static int ndrivers;
>> static int drivers_alloc;
>>
>> -#define PATTERNS(name, pattern, wordregex) \
>> - { name, NULL, -1, { pattern, REG_EXTENDED }, wordregex }
>> +#define PATTERNS(name, pattern, word_regex) \
>> + { name, NULL, -1, { pattern, REG_EXTENDED }, word_regex }
>> static struct userdiff_driver builtin_drivers[] = {
>> PATTERNS("html", "^[ \t]*(<[Hh][1-6][ \t].*>.*)$",
>> "[^<>= \t]+|[^[:space:]]|[\x80-\xff]+"),
>
>In general, it is an awesomly good idea to imitate code that is already
>there. That literally guarantees consistency (which is Good, as you
>know).
Agreed that consistency is good. However, using "wordregex" isn't
consistent. The rest of the time it is used as an identifier in the code,
it's spelled "word_regex" or "word_regexp", even before my patch.
(Declarations in: userdiff.h, builtin-grep.c, 3x diff.c, and grep.h)
In particular, the macro is used to initialize "struct userdiff_driver"s
and the relevant member of that struct uses "word_regex" before my patch.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: CR codes from git commands
From: Johannes Schindelin @ 2009-01-21 15:38 UTC (permalink / raw)
To: Brent Goodrick; +Cc: git
In-Reply-To: <18807.13411.984420.252378@hungover.brentg.com>
Hi,
On Wed, 21 Jan 2009, Brent Goodrick wrote:
> Johannes Schindelin writes:
>
> > On Tue, 20 Jan 2009, Brent Goodrick wrote:
> >
> > > Johannes Schindelin writes:
> > >
> > > > On Tue, 20 Jan 2009, Brent Goodrick wrote:
> > > >
> > > > > I am considering converting from CVS over to using git. I'm
> > > > > currently using git version 1.5.6.5 on Debian Linux "testing".
> > > >
> > > > First of all, 1.5.6.5 is from last August, so chances are that
> > > > the behavior you complain about was fixed in the meantime.
> > > > We're at 1.6.1 at the moment.
> > >
> > > Yes, I thought that was a good point, so I rebuilt from the source
> > > tarball git version 1.6.1 and retried my script and got the same
> > > behavior.
> > >
> > > > The only place I can think about where a CR is output is when
> > > > showing the progress of downloading.
> > > >
> > > > Usually, our code checks if stdout is a tty, and does not show
> > > > progress.
> > > >
> > > > As a work-around, piping into cat should work, though.
> > >
> > > Actually only redirecting stderr and then piping to cat seems to work,
> > > e.g.,:
> > >
> > > get pull 2>&1 | cat
In my test I performed one minute ago, "git pull | cat" did not show any
CR. Maybe it is the "git" instead of "get" :-)
> > > I don't mind seeing the progress lines, I just don't want git to
> > > emit any CR codes at all.
> > >
> > > How about a config option to just turn off any tty-detecting logic
> > > entirely, so that I don't have to wrap git with a lot of silly
> > > scripts that set environment variables and redirect stdout and
> > > stderr and piped into "cat"?
> >
> > Nope, the config option is not needed. This is just a Plain Old Bug
> > which needs fixing, that's all.
> >
> > Let's see what I can do today.
>
> Thanks. The fix should be to arrange it so that I can set something so
> that a bare call such as (but just "git pull"):
>
> git pull
>
> will emit no CR codes at all, ever, regardless of if there is a tty.
> Even if it is an env var, but a config setting would be ok too.
I would actually think that it should not be an env var or config setting
if piping it to "cat" does what you want: if the output is a tty, I think
it is safe to assume that you want to see the progress, and if you don't,
"| cat" is not an unreasonable thing to ask for.
Ciao,
Dscho
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Marc-André Lureau @ 2009-01-21 15:41 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <49773E48.90302@drmicha.warpmail.net>
Hi
On Wed, Jan 21, 2009 at 5:24 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> So, you get these errors on the local repo when dealing with the remote
> repo, right? I guess this means two things:
>
> 1) You are deleting a remote branch
>
> 2) Your original report could have been a bit more detailed ;)
>
> In fact, I'm still unsure about your setup and can't reproduce, unless
> "almost every git command" was vastly exaggerated, and Adeodato's
> description matches your setup. Does it?
>
It matches. Sorry if I didn't describe the problem correctly.
"almost every git command" might be exaggerated. Since I am using bash
and abusing completion, I get it in the middle of my shell, and it
confuses bash. I have to clear my terminal to continue writing my
command (C-l)
> If yes then git has basically no choice, unless you want git to leave
> HEAD in place as a detached head. This is related to how the symref is
> resolved, which in turn is related to the issue of removing remote
> branches, which in turn is related to an issue I've been meaning to look
> into quite a while ago... So, reproducibility would be nice.
Not sure I follow, but I think Adeodato mail gives you a more detailed
test case to reproduce.
thanks,
--
Marc-André Lureau
^ permalink raw reply
* Re: how to git a read only directory
From: bill lam @ 2009-01-21 15:48 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, cbill.lam
In-Reply-To: <4976F195.9030908@drmicha.warpmail.net>
On Wed, 21 Jan 2009, Michael J Gruber wrote:
> You can use the core.worktree config variable in order to specify a
> worktree (/etc) which is not directly above .git. For your git commands
> to find the .git dir you would need to set GIT_DIR or use the --git-dir
> parameter.
Michael, thanks for pointing out worktree being the trick to use.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩267 王翰 涼州詞
葡萄美酒夜光杯 欲飲琵琶馬上催 醉臥沙場君莫笑 古來征戰幾人回
^ permalink raw reply
* Re: how to git a read only directory
From: bill lam @ 2009-01-21 15:52 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: git
In-Reply-To: <4977164B.4020706@panasas.com>
On Wed, 21 Jan 2009, Boaz Harrosh wrote:
> I created a master project folder under ~home, init a new git repo,
> then symlink /etc/ onto an etc/ in the project dir, added all etc/
> files. I like the extra a/etc/fstab in the patch files better then
> a/fstab.
I create a symlink in ~/gitrepo/etc to /etc and git init an empty repo
there. However it failed in symlink when I tried to add files. Could
you give more detail how to do it? Meanwhile I use worktree method as
suggested by Michael.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩205 元稹 遣悲懷三首之一
謝公最小偏憐女 自嫁黔婁百事乖 顧我無衣搜藎篋 泥他沽酒拔金釵
野蔬充膳甘長藿 落葉添薪仰古槐 今日俸錢過十萬 與君營奠復營齋
^ permalink raw reply
* Re: how to track multiple upstreams in one repository
From: Ciprian Dorin, Craciun @ 2009-01-21 16:02 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Greg KH, david, Bryan Donlan, git
In-Reply-To: <20090120120319.GR30710@genesis.frugalware.org>
On Tue, Jan 20, 2009 at 2:03 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Tue, Jan 20, 2009 at 09:29:13AM +0200, "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> wrote:
>> :) This is something that escaped me... Could you give me the
>> exact git url for this repository? (on kernel.org I'm not able to find
>> it, just the current one...)
>
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git
>
> Have you tried this one?
Ok... I'm ashamed... :) :) This is exactly what (we all) were
looking for... Sorry.
Just one curiosity: is this older (I mean if it was created) than
when 2.6.18 or 19 was released? Because at that time I've searched for
such a repository, didn't found it and hacked the config as I've said
previously...
Ciprian Craciun.
^ permalink raw reply
* Re: [PATCH] color-words: Support diff.color-words config option
From: Boyd Stephen Smith Jr. @ 2009-01-21 16:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Santi Béjar, Thomas Rast, git, Junio C Hamano, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901210923580.7929@racer>
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]
On Wednesday 21 January 2009, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote about 'Re: [PATCH] color-words: Support
diff.color-words config option':
>On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
>> I'm not entirely satisfied with it. There should probably be some way
>> to force the default behavior (which is a bit faster) even if a global
>> config or diff driver exists. Also, I think camelCase is better than
>> runtogether so I'd prefer to change "wordregex" -> "wordRegex" across
>> the entire patch set.
>
>Well, the thing is, it _should_ be "wordRegex", _except_ in the strcmp()
>because the config helpers get a downcased key.
It would have been nice to know that last night. I spent far longer than I
should have on the "wordregex" -> "wordRegex" patch.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: how to track multiple upstreams in one repository
From: Greg KH @ 2009-01-21 16:11 UTC (permalink / raw)
To: Ciprian Dorin, Craciun; +Cc: Miklos Vajna, david, Bryan Donlan, git
In-Reply-To: <8e04b5820901210802y1102cfd0q4a3f8812f357c398@mail.gmail.com>
On Wed, Jan 21, 2009 at 06:02:51PM +0200, Ciprian Dorin, Craciun wrote:
> On Tue, Jan 20, 2009 at 2:03 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> > On Tue, Jan 20, 2009 at 09:29:13AM +0200, "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> wrote:
> >> :) This is something that escaped me... Could you give me the
> >> exact git url for this repository? (on kernel.org I'm not able to find
> >> it, just the current one...)
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git
> >
> > Have you tried this one?
>
> Ok... I'm ashamed... :) :) This is exactly what (we all) were
> looking for... Sorry.
>
> Just one curiosity: is this older (I mean if it was created) than
> when 2.6.18 or 19 was released? Because at that time I've searched for
> such a repository, didn't found it and hacked the config as I've said
> previously...
Probably not, but I really don't remember when it was created, sorry.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Caleb Cushing @ 2009-01-21 16:17 UTC (permalink / raw)
To: git
In-Reply-To: <81bfc67a0901210637j52fa7a55q51b599e9ff16f6dc@mail.gmail.com>
just a typo fix in the patch
>From 29c2873861a3aec8304529735307385e9e5c248a 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 the merge
---
git-mergetool.sh | 24 ++++++++++++++++++++----
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..ae94300 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -177,11 +177,27 @@ 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
- fi
+ 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
+ case "$merge_tool" in
kdiff3)
if base_present ; then
("$merge_tool_path" --auto --L1 "$MERGED (Base)" --L2
"$MERGED (Local)" --L3 "$MERGED (Remote)" \
--
1.6.1
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply related
* Re: Deleting remote branch pointed by remote HEAD
From: Jeff King @ 2009-01-21 16:19 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Marc-André Lureau, git
In-Reply-To: <49773E48.90302@drmicha.warpmail.net>
On Wed, Jan 21, 2009 at 04:24:56PM +0100, Michael J Gruber wrote:
> So, you get these errors on the local repo when dealing with the remote
> repo, right? I guess this means two things:
>
> 1) You are deleting a remote branch
Actually, he doesn't have to delete the remote branch; somebody else
can. The problem is that the HEAD pointer for his remote tracking
branches points to a branch that doesn't exist. This can happen because
we sometimes update the tracking branches (including deletion) without
impacting the HEAD pointer.
There are two ways that I can think of (and there may be more) to
provoke this:
1. delete a remote branch via push. The local side will helpfully
delete your local tracking branch to match what happened on the
remote. If it was the remote's HEAD, then you get a broken state
(and while we discourage pushing to the remote HEAD on a non-bare
repo, it is perfectly OK for a bare one).
2. somebody else deletes the remote branch that is the HEAD, and you
update your tracking branches via "git remote prune", which deletes
your tracking branches corresponding to any deleted remote branches.
And actually there is a slight variant on both of the above. The deleted
branch does not actually have to be the current HEAD on the remote. It
just has to match your _idea_ of the current HEAD on the remote, which
may be out of date.
Situation (1) happens entirely locally. So it can be fixed fairly easily
by checking whether the remote tracking HEAD points to a branch we are
deleting, and deleting the HEAD in that case (the code should be in
builtin-send-pack.c:update_tracking_ref). Of course you have probably
also created a broken situation on the remote, so perhaps receive-pack
should handle that.
Situation (2) could do something similar: when we see that we are about
to delete the ref pointed to by the remote tracking HEAD, we could
delete the HEAD.
But both situations are a little hack-ish to me. You are deleting the
HEAD because you don't know what the right value is from the remote end.
A better fix would be to actually pull the HEAD information down during
fetch. And I seem to recall a patch about that at some point (it
required a new protocol extension), but I don't know what become of it.
However, even if we kept the tracking HEAD totally in sync with the
remote's HEAD, it still may be possible that the remote HEAD is broken.
In which case it might be nice to detect that when pulling it down and
just leave the tracking HEAD unset.
-Peff
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Johannes Schindelin @ 2009-01-21 16:33 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901210817r49971c09kea9dc8ee5ae21572@mail.gmail.com>
Hi,
On Wed, 21 Jan 2009, Caleb Cushing wrote:
> just a typo fix in the patch
>
> >From 29c2873861a3aec8304529735307385e9e5c248a 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 the merge
>
> ---
If you look at other patch submissions, you will find that they all do it
differently. You will never see a "Date:" or "Subject:" line. You will
see a much shorter commit subject. And a more verbose commit message.
Sometimes, you will see that a commit message is not quite informative, or
does not explain the _motivation_ why it should be a good idea to do what
the patch does, and me saying so very directly (but never meaning to
offend).
Hth,
Dscho
^ permalink raw reply
* Re: how to git a read only directory
From: Boaz Harrosh @ 2009-01-21 16:46 UTC (permalink / raw)
To: Boaz Harrosh, git
In-Reply-To: <20090121155256.GB6966@b2j>
bill lam wrote:
> On Wed, 21 Jan 2009, Boaz Harrosh wrote:
>> I created a master project folder under ~home, init a new git repo,
>> then symlink /etc/ onto an etc/ in the project dir, added all etc/
>> files. I like the extra a/etc/fstab in the patch files better then
>> a/fstab.
>
> I create a symlink in ~/gitrepo/etc to /etc and git init an empty repo
> there. However it failed in symlink when I tried to add files. Could
> you give more detail how to do it? Meanwhile I use worktree method as
> suggested by Michael.
>
What? I don't know this is what I did:
[~] $ mkdir gitrepo; cd gitrepo
[gitrepo] $ git-init
[gitrepo] $ ln -s /etc
[gitrepo] $ git-add /etc/fstab
[gitrepo] $ git-commit -s
Edit commit message in editor
[gitrepo] $ git-show
commit fd6a4a72bf91526b56528f4036c525f6d6fd3dc0
Author: Boaz Harrosh <bharrosh@panasas.com>
Date: Wed Jan 21 18:36:58 2009 +0200
{REMOVEME} etc/fstab test
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
diff --git a/etc/fstab b/etc/fstab
new file mode 100644
index 0000000..2e3f8d3
--- /dev/null
+++ b/etc/fstab
@@ -0,0 +1,18 @@
+LABEL=/fc7 / ext3 noatime 1 1
+LABEL=/usr0 /usr0 ext3 noatime 1 2
+LABEL=/boot /boot ext2 noatime 1 2
+LABEL=/fc10 /alt ext3 defaults 1 2
+tmpfs /dev/shm tmpfs defaults 0 0
+devpts /dev/pts devpts gid=5,mode=620 0 0
+sysfs /sys sysfs defaults 0 0
+proc /proc proc defaults 0 0
+LABEL=SWAP-sda7 swap swap defaults 0 0
+panstor:/main /mnt/panstor nfs soft,intr,rsize=65536,wsize=65536 0 0
<... snip ...>
So in short I did nothing. I have git 1.6.0.1
Boaz
^ permalink raw reply related
* git diff, git mergetool and CRLF conversion
From: Hannu Koivisto @ 2009-01-21 16:55 UTC (permalink / raw)
To: git
Hi,
Suppose I have core.autocrlf set to true and and due to that a
version controlled file in a working tree with CRLF line endings.
If I modify such a file and then say "git diff", I get a patch with
LF line endings.
Also, if get a merge conflict with a file to which CRLF conversion
is applied and run e.g. "git mergetool -t emerge", the temporary
files representing stage2 and stage3 versions seem to have LF line
endings.
Is this intended behaviour? I'm using 1.6.1 on Cygwin.
--
Hannu
^ permalink raw reply
* git gui browser documentation bug
From: Hannu Koivisto @ 2009-01-21 17:12 UTC (permalink / raw)
To: git
Hi,
git-gui(1) says:
browser
Start a tree browser showing all files in the specified commit
(or HEAD by default).
However, if I try to run it with just "git gui browser", it doesn't
start (Cygwin, 1.6.1) or says "usage:
/usr/local/libexec/git-core/git-gui browser rev? path" (Linux,
1.6.1.28.gc32f76) -- I have to say "git gui browser HEAD".
--
Hannu
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Charles Bailey @ 2009-01-21 17:04 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901210637j52fa7a55q51b599e9ff16f6dc@mail.gmail.com>
On Wed, Jan 21, 2009 at 09:37:20AM -0500, Caleb Cushing wrote:
> ---
> git-mergetool.sh | 24 ++++++++++++++++++++----
> 1 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index 00e1337..43d2a9e 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -177,11 +177,27 @@ 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
> - fi
> + while true; do
> + printf "Use (m)erge file or (s)skip 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
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?
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.
It might be quite nice to offer the option of directly using an 'ours'
or 'theirs' as an alternative to skip for binary files. A bit like
symlinks are handled in mergetool.
Charles.
^ permalink raw reply
* Re: git diff, git mergetool and CRLF conversion
From: Charles Bailey @ 2009-01-21 17:23 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83k58ofvjt.fsf@kalahari.s2.org>
On Wed, Jan 21, 2009 at 06:55:34PM +0200, Hannu Koivisto wrote:
> Hi,
>
> Suppose I have core.autocrlf set to true and and due to that a
> version controlled file in a working tree with CRLF line endings.
> If I modify such a file and then say "git diff", I get a patch with
> LF line endings.
>
> Also, if get a merge conflict with a file to which CRLF conversion
> is applied and run e.g. "git mergetool -t emerge", the temporary
> files representing stage2 and stage3 versions seem to have LF line
> endings.
>
> Is this intended behaviour? I'm using 1.6.1 on Cygwin.
Speaking for mergetool, I believe that it's simply because mergetool
uses git cat-file which just outputs the raw contents of a blob and
doesn't do any line ending conversion.
IMHO, I think that it should probably perform the 'convert to working
tree format' change when preparing the temporary files. I'm not sure
how best to do that, but perhaps it should be using git checkout-index
with the --temp option instead of cat-file.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* cherry-pick/rebase question
From: Jay Soffian @ 2009-01-21 17:27 UTC (permalink / raw)
To: Git Mailing List
Say I have the following linear set of commits on master:
A---B---C---D---E---F---G master
And I realize that I've intermixed two topics such that I want to move
commits B and E-G to their own branch. So my result should be:
A---C'---D' master
\
B'---E'---F'---G' topic
What's the best way to do it?
I read the rebase and cherry-pick man pages, found myself confused,
tried rebase a few different ways, failed, and ended up doing what I
needed with format-patch and am. (Extract B-G with format-patch, reset
master to A, create topic branch, apply B,E,F,G to topic with am,
similarly apply C,D to master with am.)
Thanks,
j.
^ permalink raw reply
* Re: cherry-pick/rebase question
From: Jay Soffian @ 2009-01-21 17:46 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <76718490901210927m7fd3fbdey6ebd4cbfe44b1b71@mail.gmail.com>
On Wed, Jan 21, 2009 at 12:27 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> Say I have the following linear set of commits on master:
>
> A---B---C---D---E---F---G master
>
> And I realize that I've intermixed two topics such that I want to move
> commits B and E-G to their own branch. So my result should be:
>
> A---C'---D' master
> \
> B'---E'---F'---G' topic
>
> What's the best way to do it?
>
> I read the rebase and cherry-pick man pages, found myself confused,
> tried rebase a few different ways, failed, and ended up doing what I
> needed with format-patch and am. (Extract B-G with format-patch, reset
> master to A, create topic branch, apply B,E,F,G to topic with am,
> similarly apply C,D to master with am.)
Hmm, not sure why I didn't think of it earlier, but I guess the easiest way is:
(master)$ git co -b topic
(topic )$ git rebase -i A (remove C and D)
(topic )$ git co master
(master)$ git rebase -i A (remove B, E-G)
j.
^ permalink raw reply
* [PATCH 1/2] user-manual: Simplify the user configuration.
From: Felipe Contreras @ 2009-01-21 18:09 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
This is shorter, avoids the burder to think about the format of the
configuration file, and git config is already used in other places in
the manual.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 19f571a..3a9704c 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -981,13 +981,11 @@ Telling git your name
---------------------
Before creating any commits, you should introduce yourself to git. The
-easiest way to do so is to make sure the following lines appear in a
-file named .gitconfig in your home directory:
+easiest way is to use the linkgit:git-config[1] command:
------------------------------------------------
-[user]
- name = Your Name Comes Here
- email = you@yourdomain.example.com
+$ git config user.name "Your Name Comes Here"
+$ git config user.email you@yourdomain.example.com
------------------------------------------------
(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
--
1.6.1
^ permalink raw reply related
* [PATCH 2/2] Fix typo.
From: Felipe Contreras @ 2009-01-21 18:09 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1232561365-5919-1-git-send-email-felipe.contreras@gmail.com>
"its pointless" is wrong, should be "it is pointless" so "it's
pointless".
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
sha1_file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index f08493f..69fef9f 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -800,7 +800,7 @@ unsigned char* use_pack(struct packed_git *p,
if (p->pack_fd == -1 && open_packed_git(p))
die("packfile %s cannot be accessed", p->pack_name);
- /* Since packfiles end in a hash of their content and its
+ /* Since packfiles end in a hash of their content and it's
* pointless to ask for an offset into the middle of that
* hash, and the in_window function above wouldn't match
* don't allow an offset too close to the end of the file.
--
1.6.1
^ permalink raw reply related
* Re: Deleting remote branch pointed by remote HEAD
From: Daniel Barkalow @ 2009-01-21 18:30 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <20090121161940.GA20702@coredump.intra.peff.net>
On Wed, 21 Jan 2009, Jeff King wrote:
> On Wed, Jan 21, 2009 at 04:24:56PM +0100, Michael J Gruber wrote:
>
> > So, you get these errors on the local repo when dealing with the remote
> > repo, right? I guess this means two things:
> >
> > 1) You are deleting a remote branch
>
> Actually, he doesn't have to delete the remote branch; somebody else
> can. The problem is that the HEAD pointer for his remote tracking
> branches points to a branch that doesn't exist. This can happen because
> we sometimes update the tracking branches (including deletion) without
> impacting the HEAD pointer.
>
> There are two ways that I can think of (and there may be more) to
> provoke this:
>
> 1. delete a remote branch via push. The local side will helpfully
> delete your local tracking branch to match what happened on the
> remote. If it was the remote's HEAD, then you get a broken state
> (and while we discourage pushing to the remote HEAD on a non-bare
> repo, it is perfectly OK for a bare one).
>
> 2. somebody else deletes the remote branch that is the HEAD, and you
> update your tracking branches via "git remote prune", which deletes
> your tracking branches corresponding to any deleted remote branches.
>
> And actually there is a slight variant on both of the above. The deleted
> branch does not actually have to be the current HEAD on the remote. It
> just has to match your _idea_ of the current HEAD on the remote, which
> may be out of date.
>
> Situation (1) happens entirely locally. So it can be fixed fairly easily
> by checking whether the remote tracking HEAD points to a branch we are
> deleting, and deleting the HEAD in that case (the code should be in
> builtin-send-pack.c:update_tracking_ref). Of course you have probably
> also created a broken situation on the remote, so perhaps receive-pack
> should handle that.
>
> Situation (2) could do something similar: when we see that we are about
> to delete the ref pointed to by the remote tracking HEAD, we could
> delete the HEAD.
>
> But both situations are a little hack-ish to me. You are deleting the
> HEAD because you don't know what the right value is from the remote end.
> A better fix would be to actually pull the HEAD information down during
> fetch. And I seem to recall a patch about that at some point (it
> required a new protocol extension), but I don't know what become of it.
The information is available already; the only thing is that we don't have
a way to know that the user wants to get the remote's suggested HEAD; as
Junio pointed out at the time, a user might decide that "next" is the most
interesting branch, and set refs/remotes/origin/HEAD to that branch, and
therefore doesn't want it reset to the remote server's value.
That is, refs/remotes/origin/HEAD is only there to let the user abbreviate
the most useful branch of the remote; there's no reason it should reflect
the remote's HEAD, except that the remote's HEAD is a good guess if the
user hasn't said anything.
I think it might be more appropriate to just care less about a broken
symref, explain what's wrong if the user actually tries to use it, and
otherwise mostly ignore it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Felipe Contreras @ 2009-01-21 18:31 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <20090121161940.GA20702@coredump.intra.peff.net>
On Wed, Jan 21, 2009 at 6:19 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Jan 21, 2009 at 04:24:56PM +0100, Michael J Gruber wrote:
>
>> So, you get these errors on the local repo when dealing with the remote
>> repo, right? I guess this means two things:
>>
>> 1) You are deleting a remote branch
>
> Actually, he doesn't have to delete the remote branch; somebody else
> can. The problem is that the HEAD pointer for his remote tracking
> branches points to a branch that doesn't exist. This can happen because
> we sometimes update the tracking branches (including deletion) without
> impacting the HEAD pointer.
>
> There are two ways that I can think of (and there may be more) to
> provoke this:
>
> 1. delete a remote branch via push. The local side will helpfully
> delete your local tracking branch to match what happened on the
> remote. If it was the remote's HEAD, then you get a broken state
> (and while we discourage pushing to the remote HEAD on a non-bare
> repo, it is perfectly OK for a bare one).
>
> 2. somebody else deletes the remote branch that is the HEAD, and you
> update your tracking branches via "git remote prune", which deletes
> your tracking branches corresponding to any deleted remote branches.
>
> And actually there is a slight variant on both of the above. The deleted
> branch does not actually have to be the current HEAD on the remote. It
> just has to match your _idea_ of the current HEAD on the remote, which
> may be out of date.
>
> Situation (1) happens entirely locally. So it can be fixed fairly easily
> by checking whether the remote tracking HEAD points to a branch we are
> deleting, and deleting the HEAD in that case (the code should be in
> builtin-send-pack.c:update_tracking_ref). Of course you have probably
> also created a broken situation on the remote, so perhaps receive-pack
> should handle that.
>
> Situation (2) could do something similar: when we see that we are about
> to delete the ref pointed to by the remote tracking HEAD, we could
> delete the HEAD.
>
> But both situations are a little hack-ish to me. You are deleting the
> HEAD because you don't know what the right value is from the remote end.
> A better fix would be to actually pull the HEAD information down during
> fetch. And I seem to recall a patch about that at some point (it
> required a new protocol extension), but I don't know what become of it.
>
> However, even if we kept the tracking HEAD totally in sync with the
> remote's HEAD, it still may be possible that the remote HEAD is broken.
> In which case it might be nice to detect that when pulling it down and
> just leave the tracking HEAD unset.
Why should we care about the remote HEAD? Isn't that relevant only
when cloning to find out the branch to checkout?
Also, it's not nice to leave the remote repo with a broken HEAD
pointer, shouldn't git ask for a new head, or fail with a proper
message?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Markus Heidelberg @ 2009-01-21 18:49 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901210817r49971c09kea9dc8ee5ae21572@mail.gmail.com>
Caleb Cushing, 21.01.2009:
> git-mergetool.sh | 24 ++++++++++++++++++++----
> 1 files changed, 20 insertions(+), 4 deletions(-)
> + case "$ans" in
> + [mM]*)
> + break
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.
> - case "$merge_tool" in
> + case "$merge_tool" in
> kdiff3)
This doesn't seem right.
Markus
^ 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