* Re: [RFC] Distributing Windows binary package compiled with non gpl code
From: Daniel Barkalow @ 2007-12-27 22:08 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, msysgit
In-Reply-To: <e5bfff550712271032q25d135e7y47d68337e937d401@mail.gmail.com>
On Thu, 27 Dec 2007, Marco Costalba wrote:
> Packaged together with qgit.exe there are the necessary Micorsoft
> Visual C dll's. Is this a problem for someone?
It depends on how they're packaged together. If it's possible to unpack
them (into a bunch of separate files, where each is either all GPL or no
GPL), then this is "mere aggregation" and perfectly fine (assuming you're
allowed to distribute the Visual C dlls, of course). IIRC, bundled
libraries for Windows programs are stored on the user's disk as separate
files anyway, so this is automatically okay.
I'd actually be more concerned about whether you can (or should)
distribute GPL code compiled with a proprietary compiler; people who get
the binaries and the source still couldn't edit the source and generate a
corresponding binary, because they don't necessarily have the build
environment you used. On the other hand, nothing you could do differently
would be any better for anyone with the right to complain, so it shouldn't
be an issue in practice. (And a user of qgit for Windows is more likely
than usual to have MSVC anyway)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Using git for file archival/backup purposes - deletion strategy
From: Martin Langhoff @ 2007-12-27 22:08 UTC (permalink / raw)
To: Charles Bailey; +Cc: Git Mailing List
In-Reply-To: <4773D498.8040204@hashpling.org>
On Dec 28, 2007 5:36 AM, Charles Bailey <charles@hashpling.org> wrote:
> Martin Langhoff wrote:
> > Ah! Local clones won't honour --depth!. A clone from git.kernel.org
> > does get its .git/shallow file.
>
> This should be fixed in git v1.5.4-rc0 and later. For reference
> what version of git are you using?
Good point. I was using a 1.5.3xx. I can confirm it's fixed with
1.5.4.rc1.1136.g2794f - I get the shallow clone I expected.
cheers!
m
^ permalink raw reply
* checkout without touching HEAD
From: Martin Langhoff @ 2007-12-27 22:22 UTC (permalink / raw)
To: Git Mailing List
Is there a way to get a 'checkout' of a treeish _directly_ from git to
an empty (or 'no conflicting paths'-guaranteed) directory, without
touching HEAD?
Using `git-archive ... | tar -x` is a waste of time and resources -- I
do want this to be fast for large datasets. I have hacked it a bit by
backing up HEAD, using git checkout with a temporary index, and then
restoring HEAD, which I can do because my script has a big fat lock
around it. But it's very un-gittish to need a big lock around me.
Maybe there's a command I'm missing? Or a zikrit option to checkout I
haven't found?
cheers,
m
^ permalink raw reply
* Re: checkout without touching HEAD
From: Junio C Hamano @ 2007-12-27 22:38 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90712271422o7a831c09s463735ec41356b59@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> Is there a way to get a 'checkout' of a treeish _directly_ from git to
> an empty (or 'no conflicting paths'-guaranteed) directory, without
> touching HEAD?
>
> Using `git-archive ... | tar -x` is a waste of time and resources -- I
> do want this to be fast for large datasets. I have hacked it a bit by
> backing up HEAD, using git checkout with a temporary index, and then
> restoring HEAD, which I can do because my script has a big fat lock
> around it. But it's very un-gittish to need a big lock around me.
git read-tree -m -u HEAD $treeish
^ permalink raw reply
* Anomalous conflicts during git rebase
From: adr3nald0s @ 2007-12-27 22:42 UTC (permalink / raw)
To: git
On a clone of linux-2.6:
git checkout -b topic/test v2.6.15
touch drivers/a-file.c
git add drivers/a-file.c
git commit -m 'Add a file'
git checkout -b temp0 v2.6.16
git rebase topic/test
I get the following:
Applying [ACPI] handle ACPICA 20050916's acpi_resource.type rename
error: patch failed: drivers/acpi/glue.c:99
error: drivers/acpi/glue.c: patch does not apply
error: patch failed: drivers/char/hpet.c:897
error: drivers/char/hpet.c: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merged drivers/acpi/glue.c
Auto-merged drivers/acpi/pci_link.c
Auto-merged drivers/char/hpet.c
CONFLICT (content): Merge conflict in drivers/char/hpet.c
Failed to merge in the changes.
Patch failed at 0007.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
Is this a bug, or is there a reason I am seeing conflicts in files
I've never touched?
^ permalink raw reply
* Re: checkout without touching HEAD
From: Martin Langhoff @ 2007-12-27 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vsl1nix0x.fsf@gitster.siamese.dyndns.org>
On Dec 28, 2007 11:38 AM, Junio C Hamano <gitster@pobox.com> wrote:
> git read-tree -m -u HEAD $treeish
Thanks! Trying it now...
(I'm combining git with PostgreSQL's PITR snapshot+xlog technique for
an automated, reasonable-disk-footprint "rewind my webapp to any
arbitrary point in time in the last X days" facility, mainly for
edit-heavy web apps like Moodle. So far, it's looking good ;-) --
could be a killer feature for the LAPP platform... )
m
^ permalink raw reply
* Re: Anomalous conflicts during git rebase
From: Johannes Sixt @ 2007-12-27 22:57 UTC (permalink / raw)
To: adr3nald0s, git
In-Reply-To: <m3ir2ju5ce.fsf@euroclydon.lan>
adr3nald0s@gmail.com wrote:
> On a clone of linux-2.6:
>
> git checkout -b topic/test v2.6.15
> touch drivers/a-file.c
> git add drivers/a-file.c
> git commit -m 'Add a file'
> git checkout -b temp0 v2.6.16
> git rebase topic/test
>
> I get the following:
>
> Applying [ACPI] handle ACPICA 20050916's acpi_resource.type rename
..
> CONFLICT (content): Merge conflict in drivers/char/hpet.c
..
> Is this a bug, or is there a reason I am seeing conflicts in files
> I've never touched?
You are using the rebase the wrong way round.
The (first) argument to git rebase tells *where the current branch* will be
moved to, and not *which branch to move*.
So, instead of last two commands (git checkout...; git rebase...) you say
git rebase v2.6.16
and you don't need the branch temp0.
-- Hannes
^ permalink raw reply
* Re: [RFC] Distributing Windows binary package compiled with non gpl code
From: Abdelrazak Younes @ 2007-12-27 23:10 UTC (permalink / raw)
To: git; +Cc: msysgit
In-Reply-To: <alpine.LNX.1.00.0712271647130.13593@iabervon.org>
Daniel Barkalow wrote:
> On Thu, 27 Dec 2007, Marco Costalba wrote:
>
>> Packaged together with qgit.exe there are the necessary Micorsoft
>> Visual C dll's. Is this a problem for someone?
My two cents below; I hope you don't mind my interference.
>
> It depends on how they're packaged together. If it's possible to unpack
> them (into a bunch of separate files, where each is either all GPL or no
> GPL), then this is "mere aggregation" and perfectly fine (assuming you're
> allowed to distribute the Visual C dlls, of course). IIRC, bundled
> libraries for Windows programs are stored on the user's disk as separate
> files anyway, so this is automatically okay.
Yes, MSVC dlls are redistributable.
> I'd actually be more concerned about whether you can (or should)
> distribute GPL code compiled with a proprietary compiler;
This is the exact same situation as with other proprietary platforms
(Solaris, HPUx, etc). You should not make a difference for Windows IMHO.
Besides, many open source projects have no problem at all with MSVC.
> people who get
> the binaries and the source still couldn't edit the source and generate a
> corresponding binary, because they don't necessarily have the build
> environment you used.
This particular tool is free (as in beer) to download and use.
> On the other hand, nothing you could do differently
> would be any better for anyone with the right to complain, so it shouldn't
> be an issue in practice. (And a user of qgit for Windows is more likely
> than usual to have MSVC anyway)
Well said :-)
Abdel.
^ permalink raw reply
* Re: Anomalous conflicts during git rebase
From: Daniel Barkalow @ 2007-12-27 23:45 UTC (permalink / raw)
To: adr3nald0s; +Cc: git
In-Reply-To: <m3ir2ju5ce.fsf@euroclydon.lan>
On Thu, 27 Dec 2007, adr3nald0s@gmail.com wrote:
>
> On a clone of linux-2.6:
>
> git checkout -b topic/test v2.6.15
> touch drivers/a-file.c
> git add drivers/a-file.c
> git commit -m 'Add a file'
> git checkout -b temp0 v2.6.16
> git rebase topic/test
This will rebase temp0 (= v2.6.16) onto topic/test. This process
linearizes the history being rebased, and conflicts in that history (that
were resolved in the merges) show up when the second change to those lines
gets introduced.
What you probably want is
...
git commit -m 'Add a file'
git checkout -b temp0
git rebase v2.6.16
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Distributing Windows binary package compiled with non gpl code
From: Daniel Barkalow @ 2007-12-28 0:05 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: git-u79uwXL29TY76Z2rM5mHXA, msysgit-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <fl1bcn$k2h$1@ger.gmane.org>
On Fri, 28 Dec 2007, Abdelrazak Younes wrote:
> Daniel Barkalow wrote:
> > On Thu, 27 Dec 2007, Marco Costalba wrote:
> >
> > > Packaged together with qgit.exe there are the necessary Micorsoft
> > > Visual C dll's. Is this a problem for someone?
>
> My two cents below; I hope you don't mind my interference.
Not at all.
> > I'd actually be more concerned about whether you can (or should) distribute
> > GPL code compiled with a proprietary compiler;
>
> This is the exact same situation as with other proprietary platforms (Solaris,
> HPUx, etc). You should not make a difference for Windows IMHO. Besides, many
> open source projects have no problem at all with MSVC.
The difference I see is that the project's build system can use the system
toolchain without caring whether it's a proprietary one or an open source
one. That is, you can call $CC or $LD based on the interface standard, and
it doesn't fundamentally matter whether you've got a proprietary compiler
or not (of course, you'll get a different result, but that's true of
different compiler versions anyway, and build timestamps and machine and
user name will be different, etc). MSVC's build system interface is
particular to itself.
> > people who get the binaries and the source still couldn't edit the source
> > and generate a corresponding binary, because they don't necessarily have the
> > build environment you used.
>
> This particular tool is free (as in beer) to download and use.
It probably actually falls under the "system software" exception, in that
case (when distributing source, you have to include everything needed to
build the source, except for normal system software, which you can assume
the recipient has).
In any case, not an actual problem; it's just that distributing
side-by-side (the original question) is even more clearly not a problem,
in my opinion.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] git-gui: Make commit log messages end with a newline
From: Bernt Hansen @ 2007-12-28 2:15 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20071227041902.GR14735@spearce.org>
Concatenating commit log messages from multiple commits works better
when all of the commits end with a clean line break.
Its good to be strict in what you create, and lenient in what you
accept, and since we're creating here, we should always try to
Do The Right Thing(tm).
Signed-off-by: Bernt Hansen <bernt@alumni.uwaterloo.ca>
---
lib/commit.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/commit.tcl b/lib/commit.tcl
index b2d2d53..1c0586c 100644
--- a/lib/commit.tcl
+++ b/lib/commit.tcl
@@ -303,7 +303,7 @@ A rescan will be automatically started now.
puts stderr [mc "warning: Tcl does not support encoding '%s'." $enc]
fconfigure $msg_wt -encoding utf-8
}
- puts -nonewline $msg_wt $msg
+ puts $msg_wt $msg
close $msg_wt
# -- Create the commit.
--
1.5.4.rc1.21.g0e545
^ permalink raw reply related
* Re: [PATCH] git-pull: warn if only fetching tags with the -t switch
From: Junio C Hamano @ 2007-12-28 6:37 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Shawn Pearce, Daniel Barkalow
In-Reply-To: <20071227144618.32373.qmail@5b51609f839e87.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> Subject: [PATCH] git-pull: warn if only fetching tags with the -t switch
>
> git-pull -t|--tags isn't supposed to be run, remove that option from
> fetch-options.txt, and explicitely add it to git-fetch.txt. Have git pull
> still fetch tags with the -t switch, but warn afterwards to better use
> git fetch --tags, and error out.
> ---
>
> How about this?
Thanks.
We coulc go with this for the time being for 1.5.4, but I am not
absolutely confident that ...
> + # warn if only tags have been fetched
> + not_for_merge=$(sed -e '/ not-for-merge tag/d' \
> + "$GIT_DIR"/FETCH_HEAD)
> + if test "$not_for_merge" = ''; then
... FETCH_HEAD having nothing but not-for-merge tags would
happen _only_ when "pull --tags" is done. If there are (bogus)
command line other than "pull --tags" that results in this
situation, we would be issuing a wrong error message.
A trivial example. If you misconfigure your .git/config like
this:
[remote "origin"]
url = ...
fetch = refs/head/*:refs/remotes/origin/*
and say:
git pull
without even "--tags", then the resulting .git/FETCH_HEAD would
be empty, and the above test will trigger, even though the
correct diagnosis is the error message we currently give the
user.
So in that sense, the patch is a regression as it is.
Come to think of it, "git pull <anything>" is "git fetch
<anything>" followed by "git merge <something>", and what is
fetched by the first step "git fetch" and what is used by the
second step "git merge" are determined by what that <anything>
is. The rules for the case where <anything> is empty are
clearly defined in the documentation for "git pull" (partly
because it was clear what should happen if <anything> was not
empty back when the documentation was written).
It appears that the explicit case also needs documentation.
The refs fetched are:
+ Having --tags on the command line is the same as replacing
remote.$remote.fetch with refs/tags/*:refs/tags/* in the
configuration.
+ If refspecs are explicitly given from the command line, they
will be the ones that are fetched, and remotes.$remote.fetch
is consulted unless they come from the above --tags.
* Otherwise, remotes.$remote.fetch (and its equivalent in
.git/remotes/$remote) are the ones that are fetched.
* In addition, if branch.$current_branch.merge is specified but
is not covered by the above, it also is fetched.
The refs merged are:
+ If refspecs are explicitly given from the command line, they
will be the ones that are merged (nothing else is merged).
* Otherwise branch.$current_branch.merge, if exists, is what is
merged;
* Otherwise,
* globbing refspecs are ignored;
* the first refspec from the configuration (or the equivalent
from .git/remotes/$remote) is what is merged.
"git pull --tags" tells "git fetch" to fetch tags (and nothing
else -- because there is no explicit refspecs from the command
line, remotes.$remote.fetch which was replaced with the globbing
"grab all tags" is used), and as a result, there will not be
anything that is explicitly specified to be merged. Because the
user initiated such a "pull", he deserves to be told about the
"mistake".
So (technically) there is no bug but PEBCAK here.
HOWEVER.
It probably makes sense to change "git fetch [$remote] --tags"
to fetch tags _in addition to_ what are configured to be fetched
by default, instead of replacing as we currently do. We could
call the current behaviour of --tags a misfeature that invites
the user "mistake".
Such a change will make "--tags" more transparent to the second
"git merge" phase of "git pull". "git pull --tags [$remote]"
would become equivalent to "git pull [$remote]", except that as
an unrelated side effect it also fetches all tags. I suspect
that would match the user expectation better. Daniel, Shawn,
what do you think?
This is a bit more involved change than I would want to have
during -rc freeze.
^ permalink raw reply
* Re: [PATCH] git-pull: warn if only fetching tags with the -t switch
From: Junio C Hamano @ 2007-12-28 7:19 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Shawn Pearce, Daniel Barkalow
In-Reply-To: <7vve6je349.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> It appears that the explicit case also needs documentation.
But with two "oops-correction"s.
> The refs fetched are:
>
> + Having --tags on the command line is the same as replacing
> remote.$remote.fetch with refs/tags/*:refs/tags/* in the
> configuration.
>
> + If refspecs are explicitly given from the command line, they
> will be the ones that are fetched, and remotes.$remote.fetch
> is consulted unless they come from the above --tags.
s/is consulted/is ignored/;
> * Otherwise, remotes.$remote.fetch (and its equivalent in
> .git/remotes/$remote) are the ones that are fetched.
>
> * In addition, if branch.$current_branch.merge is specified but
> is not covered by the above, it also is fetched.
s/if /if no explicit refspecs are given and /;
^ permalink raw reply
* Committing, pushing and pulling for Multi-GIT-Module project
From: Imran M Yousuf @ 2007-12-28 7:43 UTC (permalink / raw)
To: git
Hi,
Compliments of the new season.
I am working with a multi-git-module project, I was wondering is it
possible to commit, push and pull all the modules at once? For pull I
think it is said explicitly that it has to be pulled individually. Is
it the same for commit and push?
Thank you & best regards,
^ permalink raw reply
* Re: [RFC] Distributing Windows binary package compiled with non gpl code
From: Marco Costalba @ 2007-12-28 8:17 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Abdelrazak Younes, git, msysgit
In-Reply-To: <alpine.LNX.1.00.0712271846380.13593@iabervon.org>
On Dec 28, 2007 1:05 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>
> It probably actually falls under the "system software" exception, in that
> case (when distributing source, you have to include everything needed to
> build the source, except for normal system software, which you can assume
> the recipient has).
>
Reading the GPL FAQ at www.gnu.org I have come up with following
clarifications that IMO apply to this case:
http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL
-------------------------------------------------------------------------------------------------
Q: I'm writing a Windows application with Microsoft Visual C++ (or
Visual Basic) and I will be releasing it under the GPL. Is dynamically
linking my program with the Visual C++ (or Visual Basic) run-time
library permitted under the GPL?
A: The GPL permits this because that run-time library normally
accompanies the compiler or interpreter you are using. So it falls
under the exception in GPL section 3.
That doesn't mean it is a good idea to write the program so that it
only runs on Windows. Doing so results in a program that is free
software but "trapped" (in this case, trapped by Windows instead of by
Java, but the effect is the same). (Historical note: As of December
2006 Sun is in the middle of rereleasing its Java platform under GNU
GPL.)
http://www.gnu.org/licenses/gpl-faq.html#GPLCompatInstaller
-----------------------------------------------------------------------------------------
Q: I would like to bundle GPLed software with some sort of
installation software. Does that installer need to have a
GPL-compatible license?
A: No. The installer and the files it installs are separate works. As
a result, the terms of the GPL do not apply to the installation
software.
http://www.gnu.org/licenses/gpl-faq.html#NonFreeTools
--------------------------------------------------------------------------------
Q: Can I release a program under the GPL which I developed using non-free tools?
A: Which programs you used to edit the source code, or to compile it,
or study it, or record it, usually makes no difference for issues
concerning the licensing of that source code.
However, if you link non-free libraries with the source code, that
would be an issue you need to deal with. It does not preclude
releasing the source code under the GPL, but if the libraries don't
fit under the "system library" exception, you should affix an explicit
notice giving permission to link your program with them. The FSF can
give you advice on doing this.
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
------------------------------------------------------------------------------------------
Q: What legal issues come up if I use GPL-incompatible libraries with
GPL software?
A: If the libraries that you link with fall within the following
exception in the GPL:
"However, as a special exception, the source code distributed need
not include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs, unless that
component itself accompanies the executable."
then you don't have to do anything special to use them; the
requirement to distribute source code for the whole program does not
include those libraries, even if you distribute a linked executable
containing them. Thus, if the libraries you need come with major parts
of a proprietary operating system, the GPL says people can link your
program with them without any conditions.
The last FAQ is not very clear IMHO because the rule says "unless that
component itself accompanies the executable" (as is the case with my
distributed dll) but after the explanation says "the requirement to
distribute source code for the whole program does not include those
libraries, even if you distribute a linked executable containing them"
Marco
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.4-rc2
From: Steffen Prohaska @ 2007-12-28 10:43 UTC (permalink / raw)
To: Git Mailing List, msysGit; +Cc: Junio C Hamano
In-Reply-To: <7v1w98lsg3.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
On Dec 27, 2007, at 4:36 AM, Junio C Hamano wrote:
> GIT 1.5.4-rc2 is available at the usual places:
The msysgit installer is now available at
http://code.google.com/p/msysgit/downloads
Steffen
^ permalink raw reply
* Hunk splitting in "git gui"
From: Wincent Colaiuta @ 2007-12-28 12:26 UTC (permalink / raw)
To: Git Mailing List
I'd use "git gui" a lot more if I could split hunks in it (like you
can in "git add --interactive").
Problem is, I have zero knowledge of Tcl/Tk. Can someone who has
knowledge of this offer an opinion on whether this would be a feasible
project for a beginner? I'm willing to have a shot at it, but before I
embark on this I'd like to know if others consider it useful and doable!
Cheers,
Wincent
^ permalink raw reply
* Re: Hunk splitting in "git gui"
From: Johannes Sixt @ 2007-12-28 12:38 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <3F129AD6-EA27-4584-B5C8-2866964AB93E@wincent.com>
Wincent Colaiuta schrieb:
> I'd use "git gui" a lot more if I could split hunks in it (like you can
> in "git add --interactive").
>
> Problem is, I have zero knowledge of Tcl/Tk. Can someone who has
> knowledge of this offer an opinion on whether this would be a feasible
> project for a beginner? I'm willing to have a shot at it, but before I
> embark on this I'd like to know if others consider it useful and doable!
Look at the sub-thread that started here:
http://article.gmane.org/gmane.comp.version-control.git/68091
Be sure not to skip the explanation why --unidiff-zero is dangerous.
-- Hannes
^ permalink raw reply
* Re: Committing, pushing and pulling for Multi-GIT-Module project
From: Miklos Vajna @ 2007-12-28 14:49 UTC (permalink / raw)
To: Imran M Yousuf; +Cc: git
In-Reply-To: <7bfdc29a0712272343j6c9b460eq97f17cea9f3a9c3b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
On Fri, Dec 28, 2007 at 01:43:37PM +0600, Imran M Yousuf <imyousuf@gmail.com> wrote:
> I am working with a multi-git-module project, I was wondering is it
> possible to commit, push and pull all the modules at once?
if you use the term 'module' as 'repo', then yes, you have to do so
individually. (of course you can write a wrapper if you want)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] gitk: use user-configured background in view definition dialog
From: Gerrit Pape @ 2007-12-28 14:51 UTC (permalink / raw)
To: Paul Mackerras, git
Have the text fields in the view definition dialog (View->New view...)
use the background color as configured through the preferences, instead
of hard-coded 'white'.
This was suggested by Paul Wise through
http://bugs.debian.org/457124
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
gitk | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 684e614..7d70c64 100755
--- a/gitk
+++ b/gitk
@@ -1881,7 +1881,7 @@ proc editview {} {
proc vieweditor {top n title} {
global newviewname newviewperm viewfiles
- global uifont
+ global uifont bgcolor
toplevel $top
wm title $top $title
@@ -1895,12 +1895,12 @@ proc vieweditor {top n title} {
-text [mc "Commits to include (arguments to git rev-list):"]
grid $top.al - -sticky w -pady 5
entry $top.args -width 50 -textvariable newviewargs($n) \
- -background white -font uifont
+ -background $bgcolor -font uifont
grid $top.args - -sticky ew -padx 5
message $top.l -aspect 1000 -font uifont \
-text [mc "Enter files and directories to include, one per line:"]
grid $top.l - -sticky w
- text $top.t -width 40 -height 10 -background white -font uifont
+ text $top.t -width 40 -height 10 -background $bgcolor -font uifont
if {[info exists viewfiles($n)]} {
foreach f $viewfiles($n) {
$top.t insert end $f
--
1.5.3.7
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.4-rc2
From: Luciano Rocha @ 2007-12-28 15:02 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List, msysGit, Junio C Hamano
In-Reply-To: <AAB76121-7F18-4506-809F-EFCAAD76F8BC@zib.de>
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]
On Fri, Dec 28, 2007 at 11:43:53AM +0100, Steffen Prohaska wrote:
>
> On Dec 27, 2007, at 4:36 AM, Junio C Hamano wrote:
>
> > GIT 1.5.4-rc2 is available at the usual places:
>
>
> The msysgit installer is now available at
>
> http://code.google.com/p/msysgit/downloads
>
Trying to install it in wine ends with:
Runtime Error (at -1:0):
Cannot Import dll:Kernel32.dll.
That popup appears immediately after running wine
Git-1.5.4-rc2-preview20071228.exe and the installation ends.
I've successfully installed a lot of PortableApps, MinGW/MSys and Vim
with that wine.
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.4-rc2
From: Alexandre Julliard @ 2007-12-28 15:16 UTC (permalink / raw)
To: Luciano Rocha; +Cc: Steffen Prohaska, Git Mailing List, msysGit, Junio C Hamano
In-Reply-To: <20071228150240.GC19928@bit.office.eurotux.com>
Luciano Rocha <luciano@eurotux.com> writes:
> On Fri, Dec 28, 2007 at 11:43:53AM +0100, Steffen Prohaska wrote:
>>
>> On Dec 27, 2007, at 4:36 AM, Junio C Hamano wrote:
>>
>> > GIT 1.5.4-rc2 is available at the usual places:
>>
>>
>> The msysgit installer is now available at
>>
>> http://code.google.com/p/msysgit/downloads
>>
>
> Trying to install it in wine ends with:
>
> Runtime Error (at -1:0):
>
> Cannot Import dll:Kernel32.dll.
>
> That popup appears immediately after running wine
> Git-1.5.4-rc2-preview20071228.exe and the installation ends.
That's because it doesn't find CreateHardLinkA. The following Wine patch
should enable the installer to succeed.
diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec
index 7bc5db3..5f6dea6 100644
--- a/dlls/kernel32/kernel32.spec
+++ b/dlls/kernel32/kernel32.spec
@@ -224,8 +224,8 @@
@ stdcall CreateFileMappingA(long ptr long long long str)
@ stdcall CreateFileMappingW(long ptr long long long wstr)
@ stdcall CreateFileW(wstr long long ptr long long long)
-# @ stub CreateHardLinkA
-# @ stub CreateHardLinkW
+@ stub CreateHardLinkA
+@ stub CreateHardLinkW
@ stdcall CreateIoCompletionPort(long long long long)
@ stdcall CreateJobObjectA(ptr str)
@ stdcall CreateJobObjectW(ptr wstr)
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.4-rc2
From: Luciano Rocha @ 2007-12-28 15:26 UTC (permalink / raw)
To: Alexandre Julliard
Cc: Steffen Prohaska, Git Mailing List, msysGit, Junio C Hamano
In-Reply-To: <87sl1m6e9h.fsf@wine.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
On Fri, Dec 28, 2007 at 04:16:26PM +0100, Alexandre Julliard wrote:
> Luciano Rocha <luciano@eurotux.com> writes:
>
> > On Fri, Dec 28, 2007 at 11:43:53AM +0100, Steffen Prohaska wrote:
> >>
> >> On Dec 27, 2007, at 4:36 AM, Junio C Hamano wrote:
> >>
> >> > GIT 1.5.4-rc2 is available at the usual places:
> >>
> >>
> >> The msysgit installer is now available at
> >>
> >> http://code.google.com/p/msysgit/downloads
> >>
> >
> > Trying to install it in wine ends with:
> >
> > Runtime Error (at -1:0):
> >
> > Cannot Import dll:Kernel32.dll.
> >
> > That popup appears immediately after running wine
> > Git-1.5.4-rc2-preview20071228.exe and the installation ends.
>
> That's because it doesn't find CreateHardLinkA. The following Wine patch
> should enable the installer to succeed.
>
Thanks. I won't have time to test it in the comming days, but it makes
sense.
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Anomalous conflicts during git rebase
From: adr3nald0s @ 2007-12-28 15:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: adr3nald0s, git
In-Reply-To: <20071227225703.B33A25A709@dx.sixt.local>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> adr3nald0s@gmail.com wrote:
>> On a clone of linux-2.6:
>>
>> git checkout -b topic/test v2.6.15
>> touch drivers/a-file.c
>> git add drivers/a-file.c
>> git commit -m 'Add a file'
>> git checkout -b temp0 v2.6.16
>> git rebase topic/test
>>
>> I get the following:
>>
>> Applying [ACPI] handle ACPICA 20050916's acpi_resource.type rename
> ..
>> CONFLICT (content): Merge conflict in drivers/char/hpet.c
> ..
>> Is this a bug, or is there a reason I am seeing conflicts in files
>> I've never touched?
>
I am not picking on you, Johannes, but I was expecting a response like
this:
> You are using the rebase the wrong way round.
I am very well aware of how rebase is intended to be used. The
components of git are not always used for their semantic purpose. As
recommended frequently on this list, it is common to bend them to your
purpose and use them in non-intuitive ways.
The purpose of the commands above is to have a git repository from
2.6.15 forward that has our code, XEN and some cherry-pick'd
back-ported fixes integrated throughout. We will be doing a lot of
git-bisect'ing to find where various things changed that break our
code and certain edge-case usages of XEN.
So my question stands and it is not, "Adr3nalD0S, why _would_ you do
this?" It is, "Why does git report conflicts that do not exist?"
P.S. This isn't the first project I have run into this on. It's just
the first one where I decided to try and do something about it.
^ permalink raw reply
* Re: Hunk splitting in "git gui"
From: Wincent Colaiuta @ 2007-12-28 15:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4774EE35.10905@viscovery.net>
El 28/12/2007, a las 13:38, Johannes Sixt escribió:
> Wincent Colaiuta schrieb:
>> I'd use "git gui" a lot more if I could split hunks in it (like you
>> can
>> in "git add --interactive").
>>
>> Problem is, I have zero knowledge of Tcl/Tk. Can someone who has
>> knowledge of this offer an opinion on whether this would be a
>> feasible
>> project for a beginner? I'm willing to have a shot at it, but
>> before I
>> embark on this I'd like to know if others consider it useful and
>> doable!
>
> Look at the sub-thread that started here:
>
> http://article.gmane.org/gmane.comp.version-control.git/68091
>
> Be sure not to skip the explanation why --unidiff-zero is dangerous.
Ah, yes now I remember seeing that thread. I didn't actually like what
was proposed in that patch (hunk-splitting on arbitrary, user-
selectable lines) and much prefer what "git add --interactive" does
(explode a hunk deterministically into multiple hunks wherever there
are intervening context lines).
Cheers,
Wincent
^ 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