* Re: feature request mergetool, skip, abort
From: Caleb Cushing @ 2009-01-21 14:26 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20090121112236.GC18488@hashpling.org>
patch was an attachement.
after looking through the list and seeing the conventions I've a fully
working one now, so I'm going to start a new thread with it.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: Newbie Query
From: Chris Willard @ 2009-01-21 14:31 UTC (permalink / raw)
To: Git List
In-Reply-To: <20090120191952.GA25322@uts.thewillards.local>
On Tue, 20 Jan 2009, Chris Willard wrote:
> Hello All,
>
> I am having a go at using git and need a bit of help.
[snip]
Thanks for all the tips - I used "git-reset --hard" to solve my
problem.
Regards,
Chris
--
-----------( "The Batman play seemed important to Crow." -- )------------
-----------( Mike Nelson )------------
Chris -----( )---- Willard
Htag.pl 0.0.23
--
This message was scanned by ESVA and is believed to be clean.
^ permalink raw reply
* Re: [PATCH] [TOPGIT] make tg remote idempotent
From: martin f krafft @ 2009-01-21 14:31 UTC (permalink / raw)
To: Uwe Kleine-König, git, Petr Baudis
In-Reply-To: <20090121110628.GA9415@strlen.de>
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
also sprach Uwe Kleine-König <ukleinek@strlen.de> [2009.01.21.2206 +1100]:
> I fixed this in my repo. Should I resend the fixed patch?
No, I will pull. Cheers,
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"arthur slapped his arms about himself to try and get his
circulation a little more enthusiastic about its job."
-- hitchhiker's guide to the galaxy
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Michael J Gruber @ 2009-01-21 14:33 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: git
In-Reply-To: <e29894ca0901210502n1ed1187bm46669a402ab4fe48@mail.gmail.com>
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?
> I found this situation non-friendly. Fortunately, I could understand
> what's going on. But a new user might be confused.
>
> Shouldn't the remote HEAD branch be updated or "protected" in some
> ways? Or should the "error" be considered as a "warning" (silently?)
>
> What do you think?
I think that git said
"warning: updating the currently checked out branch; this may cause
confusion,
as the index and working tree do not reflect changes that are now in HEAD."
after your push and that this may have rung some bells. I also think
that pushing to a non-bare remote repo (one with a worktree checked out)
is strongly advised against in multiple places, unless you know what
you're doing - which you seem to do since you were able to restore your
HEAD ;)
Cheers,
Michael
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Sebastien Cevey @ 2009-01-21 14:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Giuseppe Bilotta
In-Reply-To: <200901120225.30175.jnareb@gmail.com>
Selon Jakub Narebski <jnareb@gmail.com>:
Hello,
Sorry for not responding earlier, I was quite busy being ill and moving abroad
for a new job.
> >>> ----------------------------------------------------------------
> >>> [Actively cooking]
> >>>
> >>> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
> >>> - gitweb: Optional grouping of projects by category
> >>> - gitweb: Split git_project_list_body in two functions
> >>> - gitweb: Modularized git_get_project_description to be more generic
> >>
> >> This I think needs some further cooking. I guess with addition of one
> >> more patch to series categories could be sorted together with projects
> >> they contain, and not always have to be in fixed ordering.
> >
> > These should be moved to the Stalled category; nobody seems to be
> > discussing improvements and sending updates to the series as far as I
> > recall.
>
> I think it is just the author being slow moving; there was quite
> a bit of time between subsequent versions of this patch series.
I don't recall what was left to do on top of the series of patches I submitted,
could you refresh my mind on that if it still needs to be done? I remember the
discussion trailing off as categorized ordering was being discussed..
--
Sebastien Cevey - inso.cc
^ permalink raw reply
* [PATCH] mergetool merge/skip/abort
From: Caleb Cushing @ 2009-01-21 14:37 UTC (permalink / raw)
To: git
There are some files that I can't merge with git, and sometimes you
just want to finish merging later or move on to the next file and come
back later. My patch allows you to quit mergetool without ctrl-c, or
move on to the next file or merge the this one. pretty simple and I
think will be useful for a lot of people.
>From b647762ad179cdaaf9f844671fdf26074563b366 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..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
- 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: Marc-André Lureau @ 2009-01-21 14:38 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <49773240.7090605@drmicha.warpmail.net>
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.
>> I found this situation non-friendly. Fortunately, I could understand
>> what's going on. But a new user might be confused.
>>
>> Shouldn't the remote HEAD branch be updated or "protected" in some
>> ways? Or should the "error" be considered as a "warning" (silently?)
>>
>> What do you think?
>
> I think that git said
> "warning: updating the currently checked out branch; this may cause
> confusion,
> as the index and working tree do not reflect changes that are now in HEAD."
IIRC, it only says so if your local repo is on a branch tracking this
remote. At least, in some conditions, I didn't get this warning. When
I did second simple testing with git.git version, I also had this
warning.
> after your push and that this may have rung some bells. I also think
> that pushing to a non-bare remote repo (one with a worktree checked out)
> is strongly advised against in multiple places, unless you know what
> you're doing - which you seem to do since you were able to restore your
> HEAD ;)
Isn't HEAD also on non-bare repo, to indicate what is the default branch?
thanks,
--
Marc-André Lureau
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Adeodato Simó @ 2009-01-21 14:41 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Marc-André Lureau, git
In-Reply-To: <49773240.7090605@drmicha.warpmail.net>
* Michael J Gruber [Wed, 21 Jan 2009 15:33:36 +0100]:
> 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?
> > I found this situation non-friendly. Fortunately, I could understand
> > what's going on. But a new user might be confused.
> > Shouldn't the remote HEAD branch be updated or "protected" in some
> > ways? Or should the "error" be considered as a "warning" (silently?)
> > What do you think?
> I think that git said
> "warning: updating the currently checked out branch; this may cause
> confusion,
> as the index and working tree do not reflect changes that are now in HEAD."
> after your push and that this may have rung some bells. I also think
> that pushing to a non-bare remote repo (one with a worktree checked out)
> is strongly advised against in multiple places, unless you know what
> you're doing - which you seem to do since you were able to restore your
> HEAD ;)
I don't think Marc-André was pushing to a non-bare repo, but it doesn't
really matter, because his issue also shows up with bare repos: if you
delete the branch to which HEAD points in a remote repo, you get no
warning, and then cloning that bare repo does not fully work, because
its HEAD points to a non-existent ref.
% g clone ssh://.../foo.git
% cd foo
% g push origin :master
% cd ..
% g clone ssh://.../foo.git foo2
...
warning: remote HEAD refers to nonexistent ref, unable to checkout.
What would git usefully do in this situation, I don't know. But I
thought I'd clear up the above confusion.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Truth is the most valuable thing we have, so let's economize it.
-- Mark Twain
^ permalink raw reply
* Re: CR codes from git commands
From: Brent Goodrick @ 2009-01-21 14:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901210930370.7929@racer>
Johannes Schindelin writes:
> Hi,
>
> is there a special reason you un-Cc:ed the list?
No, my mistake. CCing the mailing list now. I was foiled into
thinking that the reply operation in my email client meant reply-all,
but instead it was set to reply-to-sender-only. Now fixed.
>
> 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
> >
> >
> > 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.
Thanks,
Brent
^ permalink raw reply
* 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
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