* Re: [PATCH] gitk: Add shortcut Ctrl-W for closing the active window
From: Chris Frey @ 2010-02-02 23:51 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <4B68A310.6000807@web.de>
On Tue, Feb 02, 2010 at 11:11:28PM +0100, Jens Lehmann wrote:
> To make the user experience between git gui and gitk more homogeneous, use
> Ctrl-W in gitk too for closing the active window. When closing the main
> window doquit is called for proper cleanup.
This is sort of like when Mozilla claims Ctrl-U to show the page source,
and you're expecting it to clear the line.
At least in Mozilla, you can configure the browser to respect the
old meanings for Ctrl-U, etc.
- Chris
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Eugene Sajine @ 2010-02-03 0:55 UTC (permalink / raw)
To: kusmabite
Cc: Johannes Schindelin, Wincent Colaiuta, Avery Pennarun,
Jacob Helwig, git
In-Reply-To: <40aa078e1002021616s3098bf53la6af93ab0949e7e@mail.gmail.com>
On Tue, Feb 2, 2010 at 7:16 PM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> On Wed, Feb 3, 2010 at 12:48 AM, Eugene Sajine <euguess@gmail.com> wrote:
>>>
>>> This is where you're wrong. The reason why commit (without --amend) is
>>> aborting when you don't save is that the default commit message is
>>> empty, not that it wasn't saved. In fact, just saving still makes in
>>> abort. You need to add something to the commit message and then save
>>> to get it to perform the commit.
>>>
>>>> Same should be applied to rebase -i and of course to commit --amend as
>>>> it is still commit operation.
>>>>
>>>
>>> "rebase -i" and "commit --amend" already has the exact same logic as
>>> commit without ammend in this regard - they abort if the buffer is
>>> empty.
>>>
>>> --
>>> Erik "kusma" Faye-Lund
>>>
>>
>> Thank you, but I'm not wrong, as i described the exact same thing
>> somewhere in my second or third message, without even knowing the
>> implementation details. I understand the reason WHY it is like it is,
>> i just don't like it as it is inconsistent and IMHO incorrect.
>>
>
> But you are. The interface isn't inconsistent. Your model of how it
> works however, is wrong.
>
> --
> Erik "kusma" Faye-Lund
>
I'm sorry, but I don't get in which part my model is so wrong? The only
difference i see between your and my explanation is that you mentioned the
fact that simply saving the pregenerated new commit message is not working
because there is no meaningful (uncommented) string inserted into the
template. But this
doesn't change the problem it self, so I don't think it is relevant.
What is relevant though is that in current workflow with "rebase -i"
you have to remove! all
commits listed for rebase and save! the file in order to cancel! rebase
operation. This is very strange user interaction model IMHO
Instead of being explicit in applying the changes, we are explicit in
cancelling the operation. Very strange...
Thanks,
Eugene
^ permalink raw reply
* Re: git-gui translation updates needed
From: Junio C Hamano @ 2010-02-03 1:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20100201151647.GB8916@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> git-gui has picked up a few new strings. Junio and I would like
> to see the new version in git 1.7.0, which means we need to get
> the new messages translated.
>
> If you maintain a translation file for git-gui, please grab the
> latest sources and send a patch for your .po file:
>
> git://git.spearce.org/git-gui.git master
>
> Thus far I think I have German, Italian and Swedish (thanks Christian
> Stimming, Christian Stimming, Christian Stimming).
I grabbed the current one and took a quick look.
"git grep POT-Creation-Date" reveals:
el.po "POT-Creation-Date: 2008-03-14 07:18+0100\n"
zh_cn.po "POT-Creation-Date: 2008-03-14 07:18+0100\n"
nb.po "POT-Creation-Date: 2008-11-16 13:56-0800\n"
hu.po "POT-Creation-Date: 2008-12-08 08:31-0800\n"
ru.po "POT-Creation-Date: 2008-12-08 08:31-0800\n"
git-gui.pot "POT-Creation-Date: 2010-01-26 15:47-0800\n"
fr.po "POT-Creation-Date: 2010-01-26 15:47-0800\n"
it.po "POT-Creation-Date: 2010-01-26 15:47-0800\n"
ja.po "POT-Creation-Date: 2010-01-26 15:47-0800\n"
sv.po "POT-Creation-Date: 2010-01-26 15:47-0800\n"
de.po "POT-Creation-Date: 2010-01-26 22:22+0100\n"
The build says:
MSGFMT po/el.msg 381 translated, 4 fuzzy, 6 untranslated.
MSGFMT po/zh_cn.msg 366 translated, 7 fuzzy, 17 untranslated.
MSGFMT po/nb.msg 474 translated, 39 untranslated.
MSGFMT po/hu.msg 514 translated.
MSGFMT po/ru.msg 513 translated, 2 untranslated.
MSGFMT po/it.msg 519 translated, 1 untranslated.
A few observations:
- It is curious that de.po is based on a version of .pot that is
different from the official git-gui.pot, even though it seems to be
up-to-date (no, I don't read German, but running "msgmerge -U po/de.po
po/git-gui.pot" doesn't seem to detect anything missing).
Build log for "de" also says that has 520 messages all translated.
- I am seeing "1 untranslated", even though it.po is based on the latest
git-gui.pot. It translates "buckets" to an empty string; somebody who
care about Italian may need to double check.
- Greek and Chinese are way out of date and Nowegian, Hungarian, and
Russian are more than one year old.
If people who can read/write Greek, Chinese, Nowegian, Hungarian, or
Russian and who do use git-gui on regular basis want to step forward to
help, it is the time.
Thanks.
^ permalink raw reply
* Re: Reacting to new commits in a poll-mirror
From: martin f krafft @ 2010-02-03 1:10 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20100202220234.GA17107@lapse.rw.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
also sprach martin f krafft <madduck@madduck.net> [2010.02.03.1102 +1300]:
> I am trying to set up Patchwork-Git integration on host A for
> a project whose Git repo is on host B. I thought I could use
> a mirror (git clone --mirror) on A and regularly fetch from B, but
> I cannot find a way (hook) to make Git on A react to new commits it
> fetched from B.
One way is to have a mirror on A, as well as a second repo: first,
fetch to synchronise the mirror, the push to the second repo, where
the post-receive hook will get executed. Works, but it's hackish.
I'd much rather have hooks react right away to the fetch.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"life is what happens to you while you're busy making other plans."
-- john lennon
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* gitk translation updates needed?
From: Junio C Hamano @ 2010-02-03 1:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <7vy6jbunu8.fsf@alter.siamese.dyndns.org>
By the way, out of curiosity I tried the same for gitk.
$ make po/gitk.pot
$ make
Generating catalog po/es.msg
msgfmt --statistics --tcl po/es.po -l es -d po/
192 translated messages, 34 fuzzy translations, 63 untranslated messages.
Generating catalog po/fr.msg
msgfmt --statistics --tcl po/fr.po -l fr -d po/
271 translated messages, 11 fuzzy translations, 7 untranslated messages.
Generating catalog po/hu.msg
msgfmt --statistics --tcl po/hu.po -l hu -d po/
287 translated messages, 1 fuzzy translation, 1 untranslated message.
Generating catalog po/it.msg
msgfmt --statistics --tcl po/it.po -l it -d po/
282 translated messages, 1 fuzzy translation, 6 untranslated messages.
Generating catalog po/ja.msg
msgfmt --statistics --tcl po/ja.po -l ja -d po/
281 translated messages, 4 fuzzy translations, 4 untranslated messages.
Generating catalog po/ru.msg
msgfmt --statistics --tcl po/ru.po -l ru -d po/
234 translated messages, 19 fuzzy translations, 36 untranslated messages.
Generating catalog po/sv.msg
msgfmt --statistics --tcl po/sv.po -l sv -d po/
289 translated messages.
^ permalink raw reply
* Re: Reacting to new commits in a poll-mirror
From: Junio C Hamano @ 2010-02-03 1:32 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20100203011050.GA23249@lapse.rw.madduck.net>
martin f krafft <madduck@madduck.net> writes:
> also sprach martin f krafft <madduck@madduck.net> [2010.02.03.1102 +1300]:
>> I am trying to set up Patchwork-Git integration on host A for
>> a project whose Git repo is on host B. I thought I could use
>> a mirror (git clone --mirror) on A and regularly fetch from B, but
>> I cannot find a way (hook) to make Git on A react to new commits it
>> fetched from B.
>
> One way is to have a mirror on A, as well as a second repo: first,
> fetch to synchronise the mirror, the push to the second repo, where
> the post-receive hook will get executed. Works, but it's hackish.
> I'd much rather have hooks react right away to the fetch.
Sorry, but I don't understand the motivation.
You are the one with a desire to know "what new things I got by 'git
fetch' I am going to run right now".
And most importantly, that "right now" is under complete control of you.
Unlike post-receive hook that was invented as a way to be triggered by an
action done by somebody else, iow, an action you (the hook owner) do not
control at all, you do not need any hook around fetch to do what you are
trying to do. You know when you run fetch. You are the only one who
updates that repository A. Until you decide to fetch, nothing will change
in the repository A.
So I don't see what you find wrong about writing your script like:
#!/bin/sh
before_fetch=$(git for-each-ref --format='%(objectname)') &&
git fetch || exit
git rev-list --all --not $before_fetch |
while read rev
do
do your patchwork magic...
done
It seems (at least to me) to be exactly the way git plumbing layer was
designed to be used.
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: SZEDER Gábor @ 2010-02-03 1:59 UTC (permalink / raw)
To: Eugene Sajine
Cc: kusmabite, Johannes Schindelin, Wincent Colaiuta, Avery Pennarun,
Jacob Helwig, git
In-Reply-To: <76c5b8581002021655k5f63b81h1c55ae87625fbfc5@mail.gmail.com>
On Tue, Feb 02, 2010 at 07:55:31PM -0500, Eugene Sajine wrote:
> On Tue, Feb 2, 2010 at 7:16 PM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> > On Wed, Feb 3, 2010 at 12:48 AM, Eugene Sajine <euguess@gmail.com> wrote:
> >>>
> >>> This is where you're wrong. The reason why commit (without --amend) is
> >>> aborting when you don't save is that the default commit message is
> >>> empty, not that it wasn't saved. In fact, just saving still makes in
> >>> abort. You need to add something to the commit message and then save
> >>> to get it to perform the commit.
> >>>
> >>>> Same should be applied to rebase -i and of course to commit --amend as
> >>>> it is still commit operation.
> >>>>
> >>>
> >>> "rebase -i" and "commit --amend" already has the exact same logic as
> >>> commit without ammend in this regard - they abort if the buffer is
> >>> empty.
> >>>
> >>> --
> >>> Erik "kusma" Faye-Lund
> >>>
> >>
> >> Thank you, but I'm not wrong, as i described the exact same thing
> >> somewhere in my second or third message, without even knowing the
> >> implementation details. I understand the reason WHY it is like it is,
> >> i just don't like it as it is inconsistent and IMHO incorrect.
> >>
> >
> > But you are. The interface isn't inconsistent. Your model of how it
> > works however, is wrong.
> >
> > --
> > Erik "kusma" Faye-Lund
> >
>
> I'm sorry, but I don't get in which part my model is so wrong? The only
> difference i see between your and my explanation is that you mentioned the
> fact that simply saving the pregenerated new commit message is not working
> because there is no meaningful (uncommented) string inserted into the
> template. But this
> doesn't change the problem it self, so I don't think it is relevant.
>
> What is relevant though is that in current workflow with "rebase -i"
> you have to remove! all
> commits listed for rebase and save! the file in order to cancel! rebase
> operation. This is very strange user interaction model IMHO
>
> Instead of being explicit in applying the changes, we are explicit in
> cancelling the operation. Very strange...
No. In case of rebase -i, exiting the editor is being explicit in
"the todo file now contains what you should do, so do it". And if the
todo file happens to be empty, then there is nothing to do, so do
nothing. The same applies to commit and commit --amend: exiting the
editor is being explicit in "the COMMIT_MSG file now contains what you
should put in the commit message". But not having a commit message is
a really bad idea, therefore git complains and doesn't do that (unless
overridden by some command line option).
Best,
Gábor
^ permalink raw reply
* How to tell if a file was renamed between two commits
From: Ron Garret @ 2010-02-03 2:29 UTC (permalink / raw)
To: git
I'm trying to write a little utility that will extract all the revisions
of a particular file. I start with a git rev-list HEAD -- filename, get
the tree objects with git cat-file commit, the file objects with git
ls-tree, and finally the file contents themselves with git cat-file
blob. It works, except in the case where the file name was changed.
git rev-list is smart enough to track those name changes, but my little
revision tracker isn't. It dies when suddenly there is no file with the
right name in the tree.
So... is there an easy way to work around this? Is there a way to get,
say, rev-list to tell me when the file it is tracking changed names? Or
a git-diff incantation? I just need something that will tell me given
two commits and a file name whether the file was renamed between those
two commits and if so what its new name is. There must be an easy way
to do this, but I can't figure out what it is.
Thanks,
rg
^ permalink raw reply
* Re: How to tell if a file was renamed between two commits
From: Shawn O. Pearce @ 2010-02-03 2:32 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-2EA926.18292002022010@news.gmane.org>
Ron Garret <ron1@flownet.com> wrote:
> I'm trying to write a little utility that will extract all the revisions
> of a particular file. I start with a git rev-list HEAD -- filename, get
> the tree objects with git cat-file commit, the file objects with git
> ls-tree, and finally the file contents themselves with git cat-file
> blob. It works, except in the case where the file name was changed.
> git rev-list is smart enough to track those name changes, but my little
> revision tracker isn't. It dies when suddenly there is no file with the
> right name in the tree.
>
> So... is there an easy way to work around this? Is there a way to get,
> say, rev-list to tell me when the file it is tracking changed names? Or
> a git-diff incantation? I just need something that will tell me given
> two commits and a file name whether the file was renamed between those
> two commits and if so what its new name is. There must be an easy way
> to do this, but I can't figure out what it is.
Maybe use the -M flag to git log, or the --follow flag to
log/rev-list?
--
Shawn.
^ permalink raw reply
* Re: How to tell if a file was renamed between two commits
From: Ron Garret @ 2010-02-03 2:48 UTC (permalink / raw)
To: git
In-Reply-To: <20100203023219.GA13092@spearce.org>
In article <20100203023219.GA13092@spearce.org>,
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Ron Garret <ron1@flownet.com> wrote:
> > I'm trying to write a little utility that will extract all the revisions
> > of a particular file. I start with a git rev-list HEAD -- filename, get
> > the tree objects with git cat-file commit, the file objects with git
> > ls-tree, and finally the file contents themselves with git cat-file
> > blob. It works, except in the case where the file name was changed.
> > git rev-list is smart enough to track those name changes, but my little
> > revision tracker isn't. It dies when suddenly there is no file with the
> > right name in the tree.
> >
> > So... is there an easy way to work around this? Is there a way to get,
> > say, rev-list to tell me when the file it is tracking changed names? Or
> > a git-diff incantation? I just need something that will tell me given
> > two commits and a file name whether the file was renamed between those
> > two commits and if so what its new name is. There must be an easy way
> > to do this, but I can't figure out what it is.
>
> Maybe use the -M flag to git log, or the --follow flag to
> log/rev-list?
Nope. git log --follow will follow through a name change but won't
actually say when the name changed happened or what the previous name of
the file was.
And actually playing around with it some more, it appears that git
rev-list doesn't actually track file renames, or at least it doesn't do
it all the time. Weird. I'm going to have to play around with this
some more.
rg
^ permalink raw reply
* Re: How to tell if a file was renamed between two commits
From: Shawn O. Pearce @ 2010-02-03 2:53 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-08A0F6.18483502022010@news.gmane.org>
Ron Garret <ron1@flownet.com> wrote:
> In article <20100203023219.GA13092@spearce.org>,
> "Shawn O. Pearce" <spearce@spearce.org> wrote:
> > > So... is there an easy way to work around this? Is there a way to get,
> > > say, rev-list to tell me when the file it is tracking changed names?
> >
> > Maybe use the -M flag to git log, or the --follow flag to
> > log/rev-list?
>
> Nope. git log --follow will follow through a name change but won't
> actually say when the name changed happened or what the previous name of
> the file was.
>
> And actually playing around with it some more, it appears that git
> rev-list doesn't actually track file renames, or at least it doesn't do
> it all the time. Weird. I'm going to have to play around with this
> some more.
Use:
git log --format=%H -M --name-status --follow -- path
I just tried it:
$ git log --format=%H -M --name-status --follow gerrit-prettify/src/main/resources/com/google/gerrit/prettify/client/prettify.js
8db22c85c49814b99639b2e6346583e9be4c289f
R100 gerrit-patch-gwtexpui/src/main/java/com/google/gwtexpui/safehtml/client/
544546fcd680f82a88df3e9eba7df8acfadf1e46
M gerrit-patch-gwtexpui/src/main/java/com/google/gwtexpui/safehtml/client/
d83ac11a52c1b6d4acae932a8495daf1e9129fdf
R100 gerrit-patch-gwtexpui/src/main/java/com/google/gwtexpui/safehtml/public/
44671f5c6929a8f05223dd359182610286ceb98a
R100 src/main/java/com/google/gerrit/public/prettify20090521/prettify.js
56fc9e3d951b0886c4781a5c8623dbc3da824f30
A src/main/java/com/google/gerrit/public/prettify20090521/prettify.js
Yay, its been renamed 3 times in its life here. :-)
--
Shawn.
^ permalink raw reply
* Re: How to tell if a file was renamed between two commits
From: Ron Garret @ 2010-02-03 2:52 UTC (permalink / raw)
To: git
In-Reply-To: <ron1-08A0F6.18483502022010@news.gmane.org>
In article <ron1-08A0F6.18483502022010@news.gmane.org>,
Ron Garret <ron1@flownet.com> wrote:
> In article <20100203023219.GA13092@spearce.org>,
> "Shawn O. Pearce" <spearce@spearce.org> wrote:
>
> > Ron Garret <ron1@flownet.com> wrote:
> > > I'm trying to write a little utility that will extract all the revisions
> > > of a particular file. I start with a git rev-list HEAD -- filename, get
> > > the tree objects with git cat-file commit, the file objects with git
> > > ls-tree, and finally the file contents themselves with git cat-file
> > > blob. It works, except in the case where the file name was changed.
> > > git rev-list is smart enough to track those name changes, but my little
> > > revision tracker isn't. It dies when suddenly there is no file with the
> > > right name in the tree.
> > >
> > > So... is there an easy way to work around this? Is there a way to get,
> > > say, rev-list to tell me when the file it is tracking changed names? Or
> > > a git-diff incantation? I just need something that will tell me given
> > > two commits and a file name whether the file was renamed between those
> > > two commits and if so what its new name is. There must be an easy way
> > > to do this, but I can't figure out what it is.
> >
> > Maybe use the -M flag to git log, or the --follow flag to
> > log/rev-list?
>
> Nope. git log --follow will follow through a name change but won't
> actually say when the name changed happened or what the previous name of
> the file was.
>
> And actually playing around with it some more, it appears that git
> rev-list doesn't actually track file renames, or at least it doesn't do
> it all the time. Weird. I'm going to have to play around with this
> some more.
>
> rg
Ah, I think I found it:
git log --follow --raw -- [filename]
gives you e.g.:
:100644 100644 01e79c3... 01e79c3... R100 foo baz
which seems to be what I'm looking for.
rg
^ permalink raw reply
* http getpass function in msysgit
From: Frank Li @ 2010-02-03 3:18 UTC (permalink / raw)
To: git, msysGit
ALL:
getpass at mingw.c is direct read character with function _getch().
GUI application, such tortoisegit will halt when http need
password input because gui don't know git wait for inputing passwords.
To resolve this problem, I have two options.
Options 1:
Check if terminal is exist, if exist, using old
method. Otherwise launch internal password dialog.
Options 2:
like openSSH, Check if terminal is not exist and
environment HTTP_ASKPASS exist, if true, run application which
HTTP_ASKPASS point, otherwise using old ways.
Which one do you prefer, I can implement it.
best regards
Frank Li
^ permalink raw reply
* Re: http getpass function in msysgit
From: Junio C Hamano @ 2010-02-03 5:32 UTC (permalink / raw)
To: Frank Li; +Cc: git, msysGit
In-Reply-To: <1976ea661002021918m19d9b37fx1872557d3c810e3a@mail.gmail.com>
Frank Li <lznuaa@gmail.com> writes:
> getpass at mingw.c is direct read character with function _getch().
> GUI application, such tortoisegit will halt when http need
> password input because gui don't know git wait for inputing passwords.
>
> To resolve this problem, I have two options.
> Options 1:
> Check if terminal is exist, if exist, using old
> method. Otherwise launch internal password dialog.
>
> Options 2:
> like openSSH, Check if terminal is not exist and
> environment HTTP_ASKPASS exist, if true, run application which
> HTTP_ASKPASS point, otherwise using old ways.
>
> Which one do you prefer, I can implement it.
Is "Neither, at least not yet" an accepted answer?
- If you look at an environment, why check terminal at all? If the
calling application wants to specify "here is the way to ask the user
for a password" with it, why not use it unconditionally?
- Why is it HTTP_ASKPASS? If other codepaths (e.g. "ssh passphrase",
"svn password") that do not have anything to do with HTTP transfer also
wants that feature, wouldn't it be easier for the users to specify one
single "password dialog" helper program, that is launched by various
parts of git, and ask "I need the HTTP password to access li.org", "I
need to unlock the ssh key for fl@li.org", etc?
^ permalink raw reply
* Re: http getpass function in msysgit
From: Frank Li @ 2010-02-03 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysGit
In-Reply-To: <7vpr4mrijt.fsf@alter.siamese.dyndns.org>
> - If you look at an environment, why check terminal at all? If the
> calling application wants to specify "here is the way to ask the user
> for a password" with it, why not use it unconditionally?
I just worry about user set such environment accident. Learn it from OpenSSH.
Unconditional is okay for me.
>
> - Why is it HTTP_ASKPASS? If other codepaths (e.g. "ssh passphrase",
> "svn password") that do not have anything to do with HTTP transfer also
> wants that feature,
You can choose environment name you like. I choose HTTP_ASKPASS just
because getpass only used at http.c
ssl_cert_password = getpass("Certificate Password: ");
OpenSSH is separated application and use own SSH_ASKPASS to ask password ...
May GIT_ASKPASS is optional name.
> wouldn't it be easier for the users to specify one
> single "password dialog" helper program, that is launched by various
> parts of git, and ask "I need the HTTP password to access li.org", "I
> need to unlock the ssh key for fl@li.org", etc?
It is nice to use one dialog for all cases. git-svn also have the same problem.
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Larry D'Anna @ 2010-02-03 6:15 UTC (permalink / raw)
To: git
In-Reply-To: <32541b131002021540g7a2834c9hacf2be5962f66515@mail.gmail.com>
* Avery Pennarun (apenwarr@gmail.com) [100202 18:41]:
> You can however add *new* stuff. That's why I suggested adding an
> option. You could even make it a config option so you only have to
> set it once (just like setting your preferred editor).
Or, he can set his $EDITOR to a script that checks the mtime.
--larry
^ permalink raw reply
* Odd error when doing "clone && cd && checkout -b"
From: Jacob Helwig @ 2010-02-03 7:00 UTC (permalink / raw)
To: Git
In talking with someone in the IRC channel, I ran across something that
I thought was very odd behavior. I'm sure there's a very simple
explanation, but I can't think of what it might be.
The person was getting "fatal: git checkout: updating paths is
incompatible with switching branches.", when they tried to create a new
tracking branch, and switch to it, with a fresh clone. I was able to
reproduce this, but only by one-lining the "clone && cd && checkout -b".
When the "checkout -b" fails from the one-lined version, immediately
doing the "checkout -b" on its own succeeds.
The output below is from zsh (4.3.10), however I get the exact same
behavior when I run the commands using bash (4.0.33). I was testing
this using Git 1.6.6.1.598.g661e2.
== One-lined Version ==
vfb-9 ~/tmp % git clone git://github.com/rich97/CakeCMP.git && cd CakeCMP && git checkout -b permissions-rewrite origin/permissions-rewrite
Initialized empty shared Git repository in /home/jhe/tmp/CakeCMP/.git/
remote: Counting objects: 1508, done.
remote: Compressing objects: 100% (1432/1432), done.
remote: Total 1508 (delta 256), reused 1235 (delta 60)
Receiving objects: 100% (1508/1508), 844.43 KiB | 104 KiB/s, done.
Resolving deltas: 100% (256/256), done.
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/permissions-rewrite' which can not be resolved as commit?
vfb-9 ~/tmp/CakeCMP on master(a026490) sigexit % git checkout -b permissions-rewrite origin/permission-rewrite
Branch permissions-rewrite set up to track remote branch permission-rewrite from origin.
Switched to a new branch 'permissions-rewrite'
== Running "checkout -b" on its own ==
vfb-9 ~/tmp % git clone git://github.com/rich97/CakeCMP.git && cd CakeCMP
Initialized empty shared Git repository in /home/jhe/tmp/CakeCMP/.git/
remote: Counting objects: 1508, done.
remote: Compressing objects: 100% (1432/1432), done.
remote: Total 1508 (delta 256), reused 1235 (delta 60)
Receiving objects: 100% (1508/1508), 844.43 KiB | 93 KiB/s, done.
Resolving deltas: 100% (256/256), done.
vfb-9 ~/tmp/CakeCMP on master(a026490) % git checkout -b permissions-rewrite origin/permission-rewrite
Branch permissions-rewrite set up to track remote branch permission-rewrite from origin.
Switched to a new branch 'permissions-rewrite'
vfb-9 ~/tmp/CakeCMP on permissions-rewrite(ca687f1) % git --version
git version 1.6.6.1.598.g661e2
-Jacob
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Matthieu Moy @ 2010-02-03 7:31 UTC (permalink / raw)
To: Eugene Sajine
Cc: kusmabite, Johannes Schindelin, Wincent Colaiuta, Avery Pennarun,
Jacob Helwig, git
In-Reply-To: <76c5b8581002021548n129b3997r48ee6f6df5a1a4eb@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> Thank you, but I'm not wrong, as i described the exact same thing
> somewhere in my second or third message, without even knowing the
> implementation details. I understand the reason WHY it is like it is,
> i just don't like it as it is inconsistent and IMHO incorrect.
Just try:
Create a file.
1) Launch emacs, save and quit.
2) Launch emacs, don't save, and quit.
>From outside, it's EXACTLY the same thing. In the first case, emacs
will just tell you "no change need to be saved" and quit, in the
second, it'll quit. Try deleting the file in the meantime, it won't
change the behavior.
Now, what would you do about this? Ignore Emacs and force people to
use vi?
People have been spending a whole thread to explain you that it's not
going to work. I think it'll either be time to acknowledge that, or to
learn C and write a patch. Or perhaps try to write it in Java to
understand why it doesn't work.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Matthieu Moy @ 2010-02-03 7:34 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Eugene Sajine, kusmabite, Johannes Schindelin, Wincent Colaiuta,
Avery Pennarun, Jacob Helwig, git
In-Reply-To: <20100203015947.GA4280@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
> No. In case of rebase -i, exiting the editor is being explicit in
> "the todo file now contains what you should do, so do it". And if the
> todo file happens to be empty, then there is nothing to do, so do
> nothing.
It's not true. The todolist is the list of things to do after you
rewind your branch to the destination branch. Strictly speaking, an
empty todolist should mean to drop all the patches (like a todolist
with just one line would mean to drop all the others). But a user
never wants to do that (otherwise, "git reset" would be the right
command), so "git rebase -i" considers it as a special case.
My 2 cents,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Odd error when doing "clone && cd && checkout -b"
From: Johannes Sixt @ 2010-02-03 7:40 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Git
In-Reply-To: <20100203070016.GA18089@vfb-9.home>
Jacob Helwig schrieb:
> vfb-9 ~/tmp % git clone git://github.com/rich97/CakeCMP.git && cd CakeCMP && git checkout -b permissions-rewrite origin/permissions-rewrite
> Initialized empty shared Git repository in /home/jhe/tmp/CakeCMP/.git/
> remote: Counting objects: 1508, done.
> remote: Compressing objects: 100% (1432/1432), done.
> remote: Total 1508 (delta 256), reused 1235 (delta 60)
> Receiving objects: 100% (1508/1508), 844.43 KiB | 104 KiB/s, done.
> Resolving deltas: 100% (256/256), done.
> fatal: git checkout: updating paths is incompatible with switching branches.
> Did you intend to checkout 'origin/permissions-rewrite' which can not be resolved as commit?
Or did you intend to track 'origin/permission-rewrite' instead ;-)
-- Hannes
PS: Please don't set Mail-Followup-To for this list.
^ permalink raw reply
* [PATCH/gitolite] Tell gitweb about repo owner via git-config
From: martin f. krafft @ 2010-02-03 8:13 UTC (permalink / raw)
To: git; +Cc: martin f. krafft, Sitaram Chamarty
Gitolite uses projects.list to set the owners for gitweb's use.
Unfortunately, this does not work for gitweb setups that set
$projectroot to a directory, thus generating the list of
repositories on the fly.
This patch changes that: gitolite now writes the gitweb.owner
configuration variable for each repository (and properly cleans up after
itself if the owner is removed).
The patch causes gitolite not to write the owner to projects.list
anymore, as this would be redundant.
The owner also needs no longer be escaped, so this patch removes the
poor man's 's/ /+/g' escaping previously in place.
Note that I am not a Perl coder. Thus there are probably better ways to
implement this, but at least it works.
Cc: Sitaram Chamarty <sitaramc@gmail.com>
Signed-off-by: martin f. krafft <madduck@madduck.net>
---
src/gl-compile-conf | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/gl-compile-conf b/src/gl-compile-conf
index e88819a..7cd5d2e 100755
--- a/src/gl-compile-conf
+++ b/src/gl-compile-conf
@@ -284,7 +284,6 @@ sub parse_conf_file
die "$WARN $fragment attempting to set description for $repo\n" if
$fragment ne 'master' and $fragment ne $repo and ($groups{"\@$fragment"}{$repo} || '') ne 'master';
$desc{"$repo.git"} = $desc;
- $owner =~ s/ /+/g if $owner; # gitweb/INSTALL wants more, but meh...!
$owner{"$repo.git"} = $owner || '';
}
else
@@ -414,16 +413,32 @@ for my $repo (sort keys %repos) {
$projlist{"$repo.git"} = 1;
# add the description file; no messages to user or error checking :)
$desc{"$repo.git"} and open(DESC, ">", $desc_file) and print DESC $desc{"$repo.git"} . "\n" and close DESC;
+ if ($owner{"$repo.git"}) {
+ # set the repository owner
+ system("git --git-dir=$repo.git config gitweb.owner '" . $owner{"$repo.git"} . "'");
+ } else {
+ # remove the repository owner setting
+ system("git --git-dir=$repo.git config --unset-all gitweb.owner 2>/dev/null");
+ }
} else {
# delete the description file; no messages to user or error checking :)
unlink $desc_file;
+ # remove the repository owner setting
+ system("git --git-dir=$repo.git config --unset-all gitweb.owner 2>/dev/null");
+ }
+
+ # unless there are other gitweb.* keys set, remove the section to keep the
+ # config file clean
+ my $keys = `git --git-dir=$repo.git config --get-regexp '^gitweb\\.' 2>/dev/null`;
+ if (length($keys) == 0) {
+ system("git --git-dir=$repo.git config --remove-section gitweb 2>/dev/null");
}
}
# update the project list
my $projlist_fh = wrap_open( ">", $PROJECTS_LIST);
for my $proj (sort keys %projlist) {
- print $projlist_fh "$proj" . ( $owner{$proj} ? " $owner{$proj}" : "" ) . "\n";
+ print $projlist_fh "$proj\n";
}
close $projlist_fh;
--
1.6.6
^ permalink raw reply related
* Re: Linux Kernel based project in git
From: Christian Eisendle @ 2010-02-03 8:32 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b131002021153t53d19e32j56be356c219c5780@mail.gmail.com>
>> For release we always generate 3 patches:
>> - BSP patch
>> - USB patch (since USB part is an external patch comming from a 3rd
>> party)
>> - WiFi patch (same as for USB)
>>
>> So my question is:
>> What's the best way for handling this inside the git repository?
>>
>> IMHO it would make sense to have 3 branches (BSP, USB, WiFi) each based
>> on
>> unmodified 2.6.22 Kernel. USB and WiFi branch is used for generating the
>> patch and for applying possible fixes. BSP branch for actual BSP related
>> feature development and fixes.
>> The changes in these branches are merged into the master branch which is
>> used for compiling/testing the whole BSP.
>
> Are you planning to submit these patches upstream at any point? If
> not, it might be easiest to just jam them all together in one branch
> and not look back. Since it seems like they probably affect quite
> different parts of the code, you could always extract a clean set of
> patches *later* and submit those patches upstream.
For BSP I plan to upstream eventually.
The basic idea was to divide the project in three different patches since
USB and WiFi comes from a third party and is not released under GPL (well,
different story...)
Keeping them in three different branches would make patch creation easier
especially if fixes are checked in into the USB/WiFi branch.
>
> But that's just my lazy advice :) The disadvantage to maintaining
> them in separate branches is that probably none of the three branches
> will work on its own anyway, since you don't have a physical device
> that only has the new USB device, or only the new WiFi device, or only
> needs the BSP but doesn't have updated USB or WiFi. Putting them in
> separate branches is therefore a bit artificial and won't buy you
> much.
At least the BSP could work on its own but for WiFi and USB you are right -
it's hard to test them seperately.
I just thought that there is a convenient way for handling such kind of
project.
Thanks,
Christian.
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Johannes Schindelin @ 2010-02-03 9:04 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Wincent Colaiuta, Avery Pennarun, Jacob Helwig, git
In-Reply-To: <76c5b8581002021609i4c05d039k35979757fbb74676@mail.gmail.com>
Hi,
On Tue, 2 Feb 2010, Eugene Sajine wrote:
> > Sorry, your "if message was not saved, abort" is so out of line with
> > any program I use that this would be highly confusing (maybe
> > "complicated" was the wrong choice of words).
>
> Frankly, i think it is in line with "git commit" and that's the only
> thing that matters here as I have no idea what programs you're talking
> about.
It's not. 'git commit' will abort if you delete all _and save_. So it is
not the saving part, it is the deleting all part. And that's exactly how
rebase -i works, or add -e: if you delete all and save, it aborts.
Ciao,
Dscho
^ permalink raw reply
* How to rebase and rename?
From: Peter Krefting @ 2010-02-03 9:05 UTC (permalink / raw)
To: Git Mailing List
Hi!
If I have a repository with a topic branch that is published, and that I
want to rebase and republish under a new name, is there an easy way of doing
that?
I.e., I want to go from
---C---D topic-1
/
--A---X---X---B master
to
---C---D topic-1
/
/ ---C'---D' topic-2
/ /
--A---X---X---B master
Currently, I do something along the lines of:
git branch topic-2 topic-1
git rebase master topic-2
but that feels wrong as it creates the "topic-2" branch pointing the
the wrong way first. Is there a way to eliminate that step?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* aborting rebase -i right at the start, was Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Johannes Schindelin @ 2010-02-03 9:08 UTC (permalink / raw)
To: Matthieu Moy
Cc: SZEDER Gábor, Eugene Sajine, kusmabite, Wincent Colaiuta,
Avery Pennarun, Jacob Helwig, git
In-Reply-To: <vpqaavqkc1s.fsf@bauges.imag.fr>
Hi,
On Wed, 3 Feb 2010, Matthieu Moy wrote:
> Strictly speaking, an empty [rebase -i] todolist should mean to drop all
> the patches (like a todolist with just one line would mean to drop all
> the others). But a user never wants to do that (otherwise, "git reset"
> would be the right command), so "git rebase -i" considers it as a
> special case.
Actually, it is a design bug, but it was the only sane way I could think
of aborting the rebase.
Note that there _are_ users who want to do that ("let me see what commits
I have, ah, oh, okay, I want none of them"). I am one of those. That's
where the underadvertised "noop" command comes in.
Ciao,
Dscho
^ 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