* Re: [PATCH] Give error when no remote is configured
From: Giovanni Bajo @ 2009-03-17 0:12 UTC (permalink / raw)
To: Jay Soffian; +Cc: Daniel Barkalow, Junio C Hamano, bernie, git
In-Reply-To: <76718490903161301qca2214cta87411bad1b0b8b5@mail.gmail.com>
On 3/16/2009 9:01 PM, Jay Soffian wrote:
> On Mon, Mar 16, 2009 at 12:55 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> No default remote is configured for your current branch, and the default
>> remote "origin" is not configured either.
>
> The use of "default" twice is slightly confusing. Perhaps:
>
> No remote is configured for the current branch, and the default
> remote "origin" is not configured either.
I'm a total newbie with git. I must say that the above sentence means
absolutely nothing to me (in either version) because of the confusing
usage of the word "remote" (twice, one as a substantive, one as an
adjective) and the word "origin" which is git jargon which I don't
master yet.
My suggestion is that you should at least add a sentence that points to
a likely solution. Something like:
(use "git remote add" to configure a remote URL)
Note that I don't have any clue if this sentece is correct and/or is the
correct solution. The above is just an example of a helpful error message.
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com
^ permalink raw reply
* Re: [StGit PATCH 1/5] Check for local changes with "goto"
From: Catalin Marinas @ 2009-03-17 10:51 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20090317070654.GA3716@diana.vm.bytemark.co.uk>
2009/3/17 Karl Hasselström <kha@treskal.com>:
> On 2009-03-16 14:56:11 +0000, Catalin Marinas wrote:
>> if not iw.worktree_clean():
>> self.__halt('Worktree not clean. Use "refresh" or "status --reset"')
>> if not iw.index.is_clean(self.stack.head):
>> self.__halt('Index not clean. Use "refresh" or "status --reset"')
[...]
> Your version doesn't generate the "Your index and worktree are both
> dirty" warning, but I guess that's OK.
The iw.worktree_clean() only checks whether the worktree is clean
relative to the index (I just tried "git update-index --refresh" after
"git add <modified file>" and it returns 0).
--
Catalin
^ permalink raw reply
* Re: [PATCH] config: test for --replace-all with one argument and fix documentation.
From: Felipe Contreras @ 2009-03-17 10:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carlos Rica, gitster, git
In-Reply-To: <alpine.DEB.1.00.0903171123530.6393@intel-tinevez-2-302>
On Tue, Mar 17, 2009 at 12:24 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 17 Mar 2009, Carlos Rica wrote:
>
>> Option --replace-all only allows at least two arguments, so
>> documentation was needing to be updated accordingly. A test showing
>> that the command fails with only one parameter is also provided.
>>
>> Signed-off-by: Carlos Rica <jasampler@gmail.com>
>
> Looks obviously correct to me. I am actually unsure if I can ACK this
> patch, as most of builtin-config.c does not look all that familiar to me
> anymore ;-)
Hehe... interesting, my first possibility of ack'ing :D (I guess)
Acked-by: Felipe Contreras <felipe.contreras@gmail.com>
--
Felipe Contreras
^ permalink raw reply
* [EGIT] assertion failure when renaming file
From: Marcus Better @ 2009-03-17 9:43 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I get this assertion failure from the Eclipse plugin 0.4.0.200903110025 whenever I try to rename an untracked file in Eclipse:
!ENTRY org.eclipse.ltk.ui.refactoring 4 4 2009-03-17 10:27:06.399
!MESSAGE null argument:
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: null argument:
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:86)
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:74)
at org.spearce.egit.core.GitMoveDeleteHook.<init>(GitMoveDeleteHook.java:37)
at org.spearce.egit.core.GitProvider.getMoveDeleteHook(GitProvider.java:55)
at org.eclipse.team.internal.core.MoveDeleteManager.getHookFor(MoveDeleteManager.java:34)
at org.eclipse.team.internal.core.MoveDeleteManager.moveFile(MoveDeleteManager.java:87)
at org.eclipse.core.internal.resources.Resource.unprotectedMove(Resource.java:1750)
at org.eclipse.core.internal.resources.Resource.move(Resource.java:1420)
at org.eclipse.ltk.core.refactoring.resource.RenameResourceChange.perform(RenameResourceChange.java:124)
at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:260)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:308)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.access$1(UIPerformChangeOperation.java:1)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation$1.run(UIPerformChangeOperation.java:66)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation$2.run(UIPerformChangeOperation.java:84)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3378)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3036)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:173)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:388)
at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.run(RefactoringWizardDialog2.java:317)
at org.eclipse.ltk.ui.refactoring.RefactoringWizard.internalPerformFinish(RefactoringWizard.java:558)
at org.eclipse.ltk.ui.refactoring.UserInputWizardPage.performFinish(UserInputWizardPage.java:154)
at
org.eclipse.ltk.ui.refactoring.resource.RenameResourceWizard$RenameResourceRefactoringConfigurationPage.performFinish(RenameResourceWizard.java:119)
at org.eclipse.ltk.ui.refactoring.RefactoringWizard.performFinish(RefactoringWizard.java:622)
at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.okPressed(RefactoringWizardDialog2.java:446)
at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:472)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1158)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3401)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3033)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation$1.run(RefactoringWizardOpenOperation.java:144)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation.run(RefactoringWizardOpenOperation.java:156)
at org.eclipse.jdt.internal.ui.refactoring.actions.RefactoringStarter.activate(RefactoringStarter.java:37)
at
org.eclipse.jdt.internal.corext.refactoring.RefactoringExecutionStarter.startRenameResourceRefactoring(RefactoringExecutionStarter.java:442)
at org.eclipse.jdt.internal.ui.refactoring.actions.RenameResourceAction.run(RenameResourceAction.java:43)
at org.eclipse.jdt.ui.actions.RenameAction.run(RenameAction.java:110)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:274)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:250)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:119)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:472)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:824)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:882)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:571)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:512)
at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:127)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1436)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1157)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1182)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1167)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1194)
at org.eclipse.swt.widgets.Widget.gtk_key_press_event(Widget.java:698)
at org.eclipse.swt.widgets.Control.gtk_key_press_event(Control.java:2765)
at org.eclipse.swt.widgets.Composite.gtk_key_press_event(Composite.java:702)
at org.eclipse.swt.widgets.Tree.gtk_key_press_event(Tree.java:1920)
at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1543)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4506)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:4099)
at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:5792)
at org.eclipse.swt.widgets.Display.eventProc(Display.java:1177)
at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:1550)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3031)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2384)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2348)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2200)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:495)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:490)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkm/cNkACgkQXjXn6TzcAQkRiACgosbIeO1X+5rhgu8HaN4IlPY1
gZkAnjH4YMIefzhsIOt+uoHPhOOFBGLG
=mWTz
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: --exec-path not always honored
From: Johannes Sixt @ 2009-03-17 10:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0903171117480.6393@intel-tinevez-2-302>
Johannes Schindelin schrieb:
> On Tue, 17 Mar 2009, Johannes Sixt wrote:
>
>> I noticed this failure if I run git from the build directory:
>>
>> $ ./git --exec-path=. gc
>
> I am not sure if "." is what you think it is; I imagine it would be
> $GIT_DIR by the time the PATH variable is adjusted.
This would be *very* bogus, wouldn't it?
> Could you try again with
>
> $ ./git --exec-path="$(pwd)" gc
>
> ?
It fails in the same way:
$ ./git --exec-path=$(pwd) gc
usage: git pack-objects blah blah...
error: failed to run repack
-- Hannes
^ permalink raw reply
* notes, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)
From: Johannes Schindelin @ 2009-03-17 10:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr60z8fkl.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 14 Mar 2009, Junio C Hamano wrote:
> * js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
> - tests: fix "export var=val"
> - notes: refuse to edit notes outside refs/notes/
> - t3301: use test_must_fail instead of !
> - t3301: fix confusing quoting in test for valid notes ref
> - notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
> - notes: only clean up message file when editing
> - handle empty notes gracefully
> - git notes show: test empty notes
> - git-notes: fix printing of multi-line notes
> - notes: fix core.notesRef documentation
> - Add an expensive test for git-notes
> - Speed up git notes lookup
> - Add a script to edit/inspect notes
> - Introduce commit notes
>
> Rebased and then kicked back to 'pu' to give the author a chance to
> rearrange if necessary. Nothing happened yet, but I see Dscho has been
> busy on msysgit side of the world, so it is understandable.
Actually, I have been busy in the real world, and msysGit was just a
consequence.
Besides, the 'notes' feature is not as important to me as 'rebase -i -p',
which I am trying hard to find the time to finish up properly.
The 'notes' changes as I have them in mind will also need some serious
discussion, as I _think_ we should really have the flexibility of a
variable fan-out. To prepare for that discussion, I'll have to do some
serious thinking, which needs time for this old brain of mine.
So do not hold your breath...
Ciao,
Dscho
^ permalink raw reply
* push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)
From: Johannes Schindelin @ 2009-03-17 10:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr60z8fkl.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 14 Mar 2009, Junio C Hamano wrote:
> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit
> - New config push.default to decide default behavior for push
>
> Replaced the old series with the first step to allow a smooth
> transition. Some might argue that this should not give any warning but
> just give users this new configuration to play with first, and after we
> know we are going to switch default some day, start the warning.
IIRC Steffen posted a patch series earlier, where he initialized
remote.origin.push upon clone (I am not sure if he provided a
corresponding patch for checkout --track), but personally, I think that
would be nicer than having a push.default.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] config: test for --replace-all with one argument and fix documentation.
From: Johannes Schindelin @ 2009-03-17 10:24 UTC (permalink / raw)
To: Carlos Rica; +Cc: felipe.contreras, gitster, git
In-Reply-To: <1237283197.10001.9.camel@equipo-loli>
Hi,
On Tue, 17 Mar 2009, Carlos Rica wrote:
> Option --replace-all only allows at least two arguments, so
> documentation was needing to be updated accordingly. A test showing
> that the command fails with only one parameter is also provided.
>
> Signed-off-by: Carlos Rica <jasampler@gmail.com>
Looks obviously correct to me. I am actually unsure if I can ACK this
patch, as most of builtin-config.c does not look all that familiar to me
anymore ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: --exec-path not always honored
From: Johannes Schindelin @ 2009-03-17 10:19 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <49BF692B.9020002@viscovery.net>
Hi,
On Tue, 17 Mar 2009, Johannes Sixt wrote:
> I noticed this failure if I run git from the build directory:
>
> $ ./git --exec-path=. gc
I am not sure if "." is what you think it is; I imagine it would be
$GIT_DIR by the time the PATH variable is adjusted.
Could you try again with
$ ./git --exec-path="$(pwd)" gc
?
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] MinGW: a hardlink implementation
From: Johannes Schindelin @ 2009-03-17 10:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List, Petr Kodl
In-Reply-To: <49BF5563.2060500@kdbg.org>
Hi,
On Tue, 17 Mar 2009, Johannes Sixt wrote:
> From: Petr Kodl <petrkodl@gmail.com>
> Date: Sat, 24 Jan 2009 15:04:39 +0100
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> This is the meat of Petr's original patch with the fixup that was
> discussed in the msysgit mailing list (WINAPI was added in the
> typedef).
To save everybody searching why WINAPI is needed: in the error case (e.g.
when you try to hard link from a different device), the stack was
corrupted, leading to a rather nasty segmentation fault (which has a
different name on Windows, just as everything else: access violation):
http://code.google.com/p/msysgit/issues/detail?id=204
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] MinGW: a helper function that translates Win32 API error codes
From: Johannes Schindelin @ 2009-03-17 10:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List, Petr Kodl
In-Reply-To: <49BF53C2.6020707@kdbg.org>
Hi,
On Tue, 17 Mar 2009, Johannes Sixt wrote:
> From: Petr Kodl <petrkodl@gmail.com>
> Date: Sat, 24 Jan 2009 15:04:39 +0100
>
> This function translates many possible Win32 error codes to suitable
> errno numbers. We will use it in our wrapper functions that need to call
> into Win32.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Dscho,
>
> I've split this [error code translation from Win32 to POSIX] off from
> the Petr's hard-link patch and moved the function to the top or mingw.c
> because we should reuse it in our other wrappers to convert error
> codes.
I fully agree.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] config: test for --replace-all with one argument and fix documentation.
From: Carlos Rica @ 2009-03-17 9:46 UTC (permalink / raw)
To: felipe.contreras, gitster, git, johannes.schindelin
Option --replace-all only allows at least two arguments, so
documentation was needing to be updated accordingly. A test showing
that the command fails with only one parameter is also provided.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
This is applied on top of current pu, using the Felipe
Contreras changes for adding parse-options to git-config.
Documentation/git-config.txt | 2 +-
builtin-config.c | 2 +-
t/t1300-repo-config.sh | 9 ++++++++-
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 82ce89e..7131ee3 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
'git config' [<file-option>] [type] --add name value
-'git config' [<file-option>] [type] --replace-all name [value [value_regex]]
+'git config' [<file-option>] [type] --replace-all name value [value_regex]
'git config' [<file-option>] [type] [-z|--null] --get name [value_regex]
'git config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
'git config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
diff --git a/builtin-config.c b/builtin-config.c
index 1a3baa1..d8da72c 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -55,7 +55,7 @@ static struct option builtin_config_options[] = {
OPT_BIT(0, "get", &actions, "get value: name [value-regex]", ACTION_GET),
OPT_BIT(0, "get-all", &actions, "get all values: key [value-regex]", ACTION_GET_ALL),
OPT_BIT(0, "get-regexp", &actions, "get values for regexp: name-regex [value-regex]", ACTION_GET_REGEXP),
- OPT_BIT(0, "replace-all", &actions, "replace all matching variables: name [value [value_regex]", ACTION_REPLACE_ALL),
+ OPT_BIT(0, "replace-all", &actions, "replace all matching variables: name value [value_regex]", ACTION_REPLACE_ALL),
OPT_BIT(0, "add", &actions, "adds a new variable: name value", ACTION_ADD),
OPT_BIT(0, "unset", &actions, "removes a variable: name [value-regex]", ACTION_UNSET),
OPT_BIT(0, "unset-all", &actions, "removes all matches: name [value-regex]", ACTION_UNSET_ALL),
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 3c06842..9c81e04 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -118,7 +118,14 @@ EOF
test_expect_success 'multiple unset is correct' 'cmp .git/config expect'
-mv .git/config2 .git/config
+cp .git/config2 .git/config
+
+test_expect_success '--replace-all missing value' '
+ test_must_fail git config --replace-all beta.haha &&
+ test_cmp .git/config2 .git/config
+'
+
+rm .git/config2
test_expect_success '--replace-all' \
'git config --replace-all beta.haha gamma'
--
1.6.0.5
^ permalink raw reply related
* Re: [PATCH 1/4] Documentation: minor grammatical fixes in git-archive.txt.
From: Michael J Gruber @ 2009-03-17 9:18 UTC (permalink / raw)
To: David J. Mellor; +Cc: gitster, git
In-Reply-To: <1237270577-17261-1-git-send-email-dmellor@whistlingcat.com>
David J. Mellor venit, vidit, dixit 17.03.2009 07:16:
> Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
[replying to the first patch since there's no cover letter]
For patches like this one, I wish we had a robust way of using "git
format-patch --color-words"... "Robust" as in "working for most
recipients + git-am".
So I applied your series locally and checked the --color-words diff.
Nice work, all 4 of them!
One minor reoccurring issue is the following type of construct:
###
The good/bad input is logged, and:
------------
$ git bisect log
------------
shows what you have done so far.
###
The first line is not a complete sentence. Neither is the last one,
which you have to read together with the code inset (that's fine), which
on the other belongs to the sentence started in line 1.
All of the above constitutes 1 sentence and should not be chopped in
parts by the colon.
I know this construct is somewhat common, but I don't think it is
correct. In any case it disrupts the reading flow. [In fact, that
disruption is the very reason why it is sometimes used in the middle of
a written sentence: as a substitute for the rhetoric element "pause".]
In the example above your patch introduces it, in other places it has
been used before. So this might my an opportunity to get rid of it
consistently ;)
Michael
^ permalink raw reply
* --exec-path not always honored
From: Johannes Sixt @ 2009-03-17 9:11 UTC (permalink / raw)
To: Git Mailing List
I noticed this failure if I run git from the build directory:
$ ./git --exec-path=. gc
usage: git pack-objects [{ -q | --progress | --all-progress }]
[--max-pack-size=N] [--local] [--incremental]
[--window=N] [--window-memory=N] [--depth=N]
[--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
[--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog]
[--include-tag] [--keep-unreachable | --unpack-unreachable]
--stdout | base-name < ref-or-object-list
error: failed to run repack
The reason is that the version of pack-objects that I have installed in
$prefix does not know the option --kept-pack-only, which ./git-repack
passes along. It doesn't matter whether I have $prefix in PATH or not.
But on the other hand:
$ ./git --exec-path=. repack -a -d
Counting objects: 104070, done.
Delta compression using 2 threads.
Compressing objects: 100% (26161/26161), done.
Writing objects: 100% (104070/104070), done.
Total 104070 (delta 76376), reused 104070 (delta 76376)
works just fine whereas without --exec-path it fails like git-gc above.
git-gc is a builtin. Should git setenv("GIT_EXEC_PATH") before it runs
other git commands?
-- Hannes
^ permalink raw reply
* Re: GIT_WORK_TREE=dir git ls-files --deleted
From: Jeff King @ 2009-03-17 9:03 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: Junio C Hamano, git
In-Reply-To: <201bac3a0903161841y6bc59fe5iaf0c221c08db5f43@mail.gmail.com>
On Tue, Mar 17, 2009 at 02:41:50AM +0100, Jonas Bernoulli wrote:
> git ls-files --deleted seams to be broken when GIT_WORK_TREE is set as
> can be observed below.
>
> Instead of just showing deleted files it also shows at least unchanged
> and modified files.
>
> I have observed this behaviour with git.git and do not know if
> released versions are affected.
I don't think it has ever worked correctly. A fix is below, but I'm
really unsure if it is right. It seems like we should be able to just
refresh the index and see its status, rather than calling the lstat
ourselves. But perhaps this is an optimization to avoid refresh (see
builtin-ls-files.c, lines 186-202). Junio?
-- >8 --
Subject: [PATCH] ls-files: require worktree when --deleted is given
The code will end up calling lstat() to check whether the
file still exists; obviously this doesn't work if we're not
in the worktree.
Signed-off-by: Jeff King <peff@peff.net>
---
The version in next has the same bug, but the code is totally different
due to parseopt-ification (but the fix is still a one-liner to set
require_work_tree when show_deleted is set).
builtin-ls-files.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 9dec282..ca6f33d 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -419,6 +419,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
}
if (!strcmp(arg, "-d") || !strcmp(arg, "--deleted")) {
show_deleted = 1;
+ require_work_tree = 1;
continue;
}
if (!strcmp(arg, "-m") || !strcmp(arg, "--modified")) {
--
1.6.2.1.137.gb6aa78
^ permalink raw reply related
* Re: [PATCH 0/2] git checkout: one bugfix and one cosmetic change
From: Jeff King @ 2009-03-17 8:43 UTC (permalink / raw)
To: Kris Shannon; +Cc: Kjetil Barvik, Git Mailing List
In-Reply-To: <e51f4f550903162156i64b64900g815ee8317720f1a0@mail.gmail.com>
On Tue, Mar 17, 2009 at 03:56:12PM +1100, Kris Shannon wrote:
> I was rather surprised to see my name on that list. A quick git log
> showed my one contribution to git-parse-remote way pack in
> August 2005.
>
> I'd forgotten about that and was feeling all warm and fuzzy until I did:
> git log -- git-parse-remote
>
> and saw that it was deleted a week later :(
Heh. The current list just counts commits, which is nice and fast. But
one could also "git blame" all of the content from master and credit
people based either on:
- number of surviving lines in the current codebase (which obviously
would give very rankings for people, as the number of lines added
in a commit is not constant)
- number of commits which have surviving lines
Doing such a calculation would be pretty slow, though, I imagine. And it
would of course remove you from the list. :)
-Peff
^ permalink raw reply
* Re: fetch and pull
From: Sverre Rabbelier @ 2009-03-17 8:36 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090317083452.GJ18475@coredump.intra.peff.net>
Heya,
On Tue, Mar 17, 2009 at 09:34, Jeff King <peff@peff.net> wrote:
> On Mon, Mar 16, 2009 at 09:43:47PM +0100, Sverre Rabbelier wrote:
> Erny zra rapelcg va gurve urnqf.
I always encrypt my messages with two-round ROT-13.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: fetch and pull
From: Jeff King @ 2009-03-17 8:34 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0903161343v458dec59oaae92794a367888c@mail.gmail.com>
On Mon, Mar 16, 2009 at 09:43:47PM +0100, Sverre Rabbelier wrote:
> On Mon, Mar 16, 2009 at 21:39, John Dlugosz <JDlugosz@tradestation.com> wrote:
> > PT09IFJlOiA9PT0NCllvdSB2ZXJ5IGxpa2VseSBkbyBub3Qgd2FudCB0aGUg
>
> Forgot to turn off encryption?
Erny zra rapelcg va gurve urnqf.
-Peff
^ permalink raw reply
* Re: [TopGit PATCH] tg-patch: fix invocation in sub working tree directory
From: Uwe Kleine-König @ 2009-03-17 8:33 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Petr Baudis, git, martin f krafft
In-Reply-To: <1237241299-25515-1-git-send-email-bert.wesarg@googlemail.com>
Hello again,
On Mon, Mar 16, 2009 at 11:08:19PM +0100, Bert Wesarg wrote:
> --- a/tg-patch.sh
> +++ b/tg-patch.sh
> @@ -50,13 +50,18 @@ cat_file "$topic:.topmsg"
> echo
> [ -n "$(git grep $diff_opts '^[-]--' ${diff_committed_only:+"$name"} -- ".topmsg")" ] || echo '---'
>
> +# if we are in a sub working tree dir, we need to prefix all file names from
> +# git diff --name-only with this cdup
> +cdup=$(git rev-parse --show-cdup)
> +
> # Evil obnoxious hack to work around the lack of git diff --exclude
> git_is_stupid="$(mktemp -t tg-patch-changes.XXXXXX)"
> git diff --name-only $diff_opts "$base_rev" ${diff_committed_only:+"$name"} -- |
> fgrep -vx ".topdeps" |
> fgrep -vx ".topmsg" >"$git_is_stupid" || : # fgrep likes to fail randomly?
> if [ -s "$git_is_stupid" ]; then
> - cat "$git_is_stupid" | xargs git diff --patch-with-stat $diff_opts "$base_rev" ${diff_committed_only:+"$name"} --
> + sed -e "s#^#$cdup#" "$git_is_stupid" |
> + xargs git diff --patch-with-stat $diff_opts "$base_rev" ${diff_committed_only:+"$name"} --
My not move pretty_tree from tg-export.sh to tg.sh and use that.
i.e.
git diff $someopts "$(pretty_tree "$base_rev")" "$(pretty_tree "...")"
then we wouldn't need that git_is_stupid-hack and the relative path name
thinggy wouldn hurt us.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: git confusing a submodule & subdirectory?
From: Jeff King @ 2009-03-17 8:32 UTC (permalink / raw)
To: Juan Zanos; +Cc: git
In-Reply-To: <135FFBD1-83C2-4538-8311-A69A0D7D7016@talkhouse.com>
On Mon, Mar 16, 2009 at 02:39:11PM -0400, Juan Zanos wrote:
> Is it possible for git to confuse a submodule with a subdirectory? When I
> modify my submodule git seems to think the directory has changed. A
> commit isn't going to add all that content to the containing repository.
> Is it?
It's possible that git is confusing them. There was a bug where
git-status with some configurations would show submodules as untracked
files. It was fixed by 98fa473 (refactor handling of "other" files in
ls-files and status, 2008-10-16), which is in v1.6.0.4. Depending on
your git version, you may be seeing that bug.
Otherwise, it's hard to say without more information. Can you show us
what commands you're running, what output you're seeing, and how it
differs from what you expect?
-Peff
^ permalink raw reply
* Re: [PATCH] Tests: use test_cmp instead of diff where possible
From: Jeff King @ 2009-03-17 8:28 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1237124036-1348-1-git-send-email-vmiklos@frugalware.org>
On Sun, Mar 15, 2009 at 02:33:56PM +0100, Miklos Vajna wrote:
> I intentionally did not touch t5000 - using test_cmp -r works for me,
> since the default is diff -u, but that would break the setup of users
> where GIT_TEST_CMP is set to cmp.
Definitely "test_cmp -r" is a bad idea since we don't know what
underlies it. But I wonder how portable "diff -r" is. Wasn't it a point
of contention in the recent cvsimport tests that were added (and Michael
ended up writing a mini recursive differ using some shell commands)?
OTOH, I haven't seen any complaints about it, so perhaps it is fine to
leave it.
-Peff
^ permalink raw reply
* Re: Not pushing all branches?
From: Jeff King @ 2009-03-17 8:24 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <874oxwgbcr.fsf@catnip.gol.com>
On Sat, Mar 14, 2009 at 10:08:20AM +0900, Miles Bader wrote:
> e.g., "git diff REMOTE_BRANCH" to see what updates are pending if I
> merge... Also, it would be nice to have a more concise way to say
> "git merge REMOTE_BRANCH".
>
> I'm not sure "-" seems like the best syntax though... maybe it's a bit
> _too_ short.
>
> [Is there a general standard syntax for "keywords" in git, e.g., to
> distinguish them from branch/rev names? I mean, if the standard syntax
> were "@foo", then one could imagine "git diff @remote" or something.]
I think all-caps is the closest we get. E.g., you probably don't want to
name a branch MERGE_HEAD, ORIG_HEAD, FETCH_HEAD, etc. But it's purely
advisory; you _can_ make such branches and then deal with the ensuing
"ambiguous ref" messages.
-Peff
^ permalink raw reply
* Re: Transparently encrypt repository contents with GPG
From: Jeff King @ 2009-03-17 8:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael J Gruber, Sverre Rabbelier, Thomas Rast, Michael J Gruber,
Matthias Nothhaft, git
In-Reply-To: <7vy6v9f9zn.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 13, 2009 at 01:23:08PM -0700, Junio C Hamano wrote:
> As the sole raison d'etre of diff.textconv is to allow potentially lossy
> conversion (e.g. msword-to-text) applied to the preimage and postimage
> pair of contents (that are supposed to be "clean") before giving a textual
> diff to human consumption, the above config may appear to work, but if you
> really want an encrypted repository, you should be using an encrypting
> filesystem. That would give an added benefit that the work tree
> associated with your repository would also be encrypted.
I can think of one reason that having git do the encryption might be
beneficial: pushing to an untrusted source.
If you encrypted all blobs but kept trees and commits in plaintext, you
could retain (some of) the benefits of git's incremental push. The
downsides, though, are:
1. You are revealing the hashes of your blobs' plaintext. Which means
I can try brute-forcing your blobs by checking against a hash
function.
2. The remote can't actually look at the blobs. The most obvious
problem with this is that you can't send it thin packs, since it
can't actually resolve deltas.
And given the ensuing mess that it would make of the code to
conditionally say "Oh, we have this object, but you're not allowed to
read it", it is almost certainly not worth it.
But maybe somebody can prove me wrong and design a system that allows
efficient encrypted pushing to a non-trusted remote and also doesn't
suck.
-Peff
^ permalink raw reply
* Re: [TopGit PATCH] tg-patch: fix invocation in sub working tree directory
From: Uwe Kleine-König @ 2009-03-17 8:02 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Petr Baudis, git, martin f krafft
In-Reply-To: <1237241299-25515-1-git-send-email-bert.wesarg@googlemail.com>
On Mon, Mar 16, 2009 at 11:08:19PM +0100, Bert Wesarg wrote:
> tg patch won't work in a sub directory of the working tree, because 'git diff
> --name-only' prints the names relative to the top working tree.
Hhhm, that's not exactly the problem.
git diff --patch-with-stat 45c82b5 t/trivial/typo-kernel -- $path
expects $path to be relative to the top working tree.
IMHO this is a strange behaviour of core git when comparing two trees
(and not a tree and the wc). Moreover as the output uses "absolute"
paths:
ukleinek@cassiopeia:~/gsrc/linux-2.6/fs$ git diff --patch-with-stat 45c82b5 t/trivial/typo-kernel -- proc/nommu.c | diffstat -p0
b/fs/proc/nommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)
From: Jeff King @ 2009-03-17 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprgiysow.fsf@gitster.siamese.dyndns.org>
On Sun, Mar 15, 2009 at 09:53:19PM -0700, Junio C Hamano wrote:
> But in reality, contributors who had leftover topics on 'next' simply
> stopped working on their topics on 'next' without spending the freed up
> time on concentrating on 'master'. In an ideal world, the choice would be
> between "git time on 'next'" vs "git time on 'master'", and closing 'next'
> was meant to force the choice, but instead the outcome became "less git
> time until 'next' reopens".
I think that is a reasonable argument for keeping 'next' open, and it
seems to be borne out by this experiment (the post-1.6.2 period seemed
no better or worse for bugfixes to me).
Now the only problem with keeping next open is that the maintainer
misses out on the relative lull in activity during release freeze to
catch up on his day job work. But if you can handle that, I'm certainly
in no position to complain. :)
-Peff
^ 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