* 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
* 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: [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
* 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
* [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: [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
* 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: 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: 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: 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
* 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: 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
* 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: 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
* 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
* [RFC] Distributing Windows binary package compiled with non gpl code
From: Marco Costalba @ 2007-12-27 18:32 UTC (permalink / raw)
To: git-u79uwXL29TY76Z2rM5mHXA, msysgit-/JYPxA39Uh5TLH3MbocFFw
It seems I have finally worked out a binary installation of qgit under Windows:
http://digilander.libero.it/mcostalba/qgit2.1rc1_win.exe
It seems to work with msysgit distribution of git. It DOES NOT work as
expected with Cygwin git that IMHO is very broken for qgit. I ended up
giving the blame to mingw, but after testing the MSVC compiled qgit
both with msysgit and cygwin git I have to say that the problem
*probably* is not in mingw but in cygwin.
Anyhow the MSVC 2008 compiled qgit seems stable and works as
advertised. Now that's the question:
Packaged together with qgit.exe there are the necessary Micorsoft
Visual C dll's. Is this a problem for someone?
I could try to compile again everything with mingw and test if under
msysgit the artifacts that appear with cygwin are fixed, if this
succeed I could prepare a binary package built with mingw and
distribute this instead, but would be this necessary?
qgit is GPL and I for sure want to be stick to GPL, so I don't know if
this can be an issue.
Thanks for help me in clarifing this point
Marco
P.S: Just to be fair I have to say that developing under Windows with
MSVC is much easier, because the debugging tools available with MSVC
2008 are very advanced and powerful, nothing similar exists _for
Window_ in the GPL camp. Indeed MSVC (together with SQL Server) are
(the only) two good products from MS, so good that even do not seem
produced by Microsoft !
^ permalink raw reply
* Re: Using git for file archival/backup purposes - deletion strategy
From: Charles Bailey @ 2007-12-27 16:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90712261443t6aa0cd76u46d8ae88fc7c1eba@mail.gmail.com>
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?
Charles.
^ permalink raw reply
* [PATCH] git-pull: warn if only fetching tags with the -t switch
From: Gerrit Pape @ 2007-12-27 14:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsr0ifqi.fsf@gitster.siamese.dyndns.org>
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?
Documentation/fetch-options.txt | 8 --------
Documentation/git-fetch.txt | 8 ++++++++
git-pull.sh | 9 +++++++++
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index da03422..debdc87 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -29,14 +29,6 @@
and stores them locally. This option disables this
automatic tag following.
--t, \--tags::
- Most of the tags are fetched automatically as branch
- heads are downloaded, but tags that do not point at
- objects reachable from the branch heads that are being
- tracked will not be fetched by this mechanism. This
- flag lets all tags and their associated objects be
- downloaded.
-
-k, \--keep::
Keep downloaded pack.
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 9003473..3cdac7f 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -33,6 +33,14 @@ OPTIONS
-------
include::fetch-options.txt[]
+-t, \--tags::
+ Most of the tags are fetched automatically as branch
+ heads are downloaded, but tags that do not point at
+ objects reachable from the branch heads that are being
+ tracked will not be fetched by this mechanism. This
+ flag lets all tags and their associated objects be
+ downloaded.
+
include::pull-fetch-param.txt[]
include::urls-remotes.txt[]
diff --git a/git-pull.sh b/git-pull.sh
index 698e82b..ab15eda 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -112,6 +112,15 @@ case "$merge_head" in
exit 1;;
*) exit $?;;
esac
+ # 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
+ echo >&2 "Fetching tags only, you probably meant:"
+ echo >&2 " git fetch --tags"
+ exit 1;
+ fi
+
curr_branch=${curr_branch#refs/heads/}
echo >&2 "You asked me to pull without telling me which branch you"
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] git-pull: don't complain about branch merge config if only fetching tags
From: Junio C Hamano @ 2007-12-27 10:39 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20071227093016.18337.qmail@e6d9fb481b7087.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
>> I've seen this patch on this list in the past, but isn't "git
>> pull -t" a user-error?
>
> If so, we shouldn't advertise the -t switch in the git-pull(1) manpage.
Perhaps. Patches are welcomed as always.
> As it stands, I'd understand 'git pull -t' as 'fetch _all_ tags and
> branch heads and merge according to the configuration'.
Yeah, but that would mean that the current error message needs
to be kept, as that is the logical conclusion of "merge
according to the configuration". Which is not so nice.
Perhaps using the same logic as your patch to detect the case of
"pull --tags and nothing else" case, and exit with non-zero
saying "you probably meant fetch --tags" would be a sane
compromise? I dunno.
^ permalink raw reply
* Re: [PATCH] git-pull: don't complain about branch merge config if only fetching tags
From: Gerrit Pape @ 2007-12-27 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x3oatvi.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 21, 2007 at 08:35:13AM -0800, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
> > When running git pull with the -t switch, it properly fetches tags, but
> > complains about missing information on how to merge. Since there's
> > nothing to merge, make git-pull simply exit after fetching the tags.
> I've seen this patch on this list in the past, but isn't "git
> pull -t" a user-error?
If so, we shouldn't advertise the -t switch in the git-pull(1) manpage.
As it stands, I'd understand 'git pull -t' as 'fetch _all_ tags and
branch heads and merge according to the configuration'.
Regards, Gerrit.
^ permalink raw reply
* Re: Using git for file archival/backup purposes - deletion strategy
From: Johannes Sixt @ 2007-12-27 9:18 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90712261443t6aa0cd76u46d8ae88fc7c1eba@mail.gmail.com>
Martin Langhoff schrieb:
> What I am not 100% clear on is the "old history" deletion strategy.
> The history will be *strictly* linear, so my intention is to keep the
> last N commits, by overriding the parent of the Nth commit that git
> log lists with a "shallow" entry in $GIT_DIR/shallow as documented in
> Documentation/technical/shallow.txt , and call gc after that.
>
> Is that the correct way to "forget" old history? Searching high and
> low in the list, I fail to find a definitive answer. Shallow and
> grafts entries are discussed as ways of doing this, but I can't find a
> "correct" way of doing this.
I'm doing something like this. Basically:
git rev-parse "HEAD~$N" > .git/info/grafts
git filter-branch -f HEAD
If you omit filter-branch, then a repack -a -d will corrupt the repository
(I think) unless you keep the grafts file with it and in all its clones
forever.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Point out merged submodule maintainers as better addresses for patches
From: Junio C Hamano @ 2007-12-27 4:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: paulus, git
In-Reply-To: <20071227041220.GA22256@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio doesn't directly manage the git-gui or gitk-git subdirectories
> within git.git; these are currently managed by other individuals
> and then periodically merged to git.git. Users often send patches
> to Junio for these directories when they should be directed at the
> current maintainer instead, so we should point out these special
> cases in the SubmittingPatches documentation.
This is a good start, but I think it would be good to mention
that contributors should at least Cc: the people who have been
heavily involved in the past in the surrounding area of the code
or documentation (not necessarily the last person who touched
the area) the patch attempts to improve and/or enhance.
Parts of the system are "actively managed" by people other than
me even though they aren't merged with the subtree strategy.
The areas I mentioned in MaintNotes (in 'todo') are:
- git-svn is generally deferred to Eric, unless the patch is
truly trivial.
- Documentation/user-manual.txt is primarily JBF's bailiwick.
- Nico is the guy around pack generation.
- Jakub, Luben and Pasky are more familiar than I am with
gitweb.
In fact, I would rather see any nontrivial patch to be first
sent "To: " such people with "Cc: " the list. After it has been
improved into a good enough shape in the discussion that follows
(i.e. success stories to back it up, and without regression
reports and objections), I can pick up the last round directly
from the list, or the active maintainer in the area (if exists;
it might be a better wording to call them "subsystem
maintainers") can forward it to me to apply after a final
submission is made. Sending the final submission to the
subsystem maintainer who forwards it to the higher level is what
the kernel folks regularly do, but I do not think we are large
enough to require such a formality.
^ permalink raw reply
* Re: [PATCH] Force new line at end of commit message
From: Shawn O. Pearce @ 2007-12-27 4:19 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <87myrxqrev.fsf@gollum.intra.norang.ca>
Bernt Hansen <bernt@alumni.uwaterloo.ca> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> > its clear in both the email and in the commit log that the change is
> > a git-gui change. Remember, git-gui's logs show up in the core Git
> > logs (as its merged with -s subtree) so having that git-gui: prefix
> > does help people to localize the change within the overall suite.
>
> This is my first attempt at creating a patch for git (even if it is
> mostly trivial in this case) and I wasn't aware of the git-gui.gitk repo
> and conventions regarding the commit message. I just tried to follow
> what was in Documentation/SubmittingPatches. I'll try to do better next
> time :)
Its a good first attempt. I also just sent a patch to Junio to try
and make this "special case" of directing git-gui changes to me more
clear for new folk.
> Forcing a LF on the end of the commit message feels wrong to me too.
I think Junio just convinced me otherwise.
We probably should change git-gui to always end the last line of
the message with an LF. To be honest I'm not really sure why it
doesn't do that now. ;-)
> The patch as it stands should probably not be applied.
But I think that is now only because the commit message could be
clarified to state that its for git-gui (e.g. start with "git-gui:")
and probably shouldn't be so specific to rebase -i's breakage but
instead talk about how 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).
If you respin the patch with a more descriptive message I'll put
it into 0.9.1.
--
Shawn.
^ permalink raw reply
* [PATCH] Point out merged submodule maintainers as better addresses for patches
From: Shawn O. Pearce @ 2007-12-27 4:12 UTC (permalink / raw)
To: Junio C Hamano, paulus; +Cc: git
Junio doesn't directly manage the git-gui or gitk-git subdirectories
within git.git; these are currently managed by other individuals
and then periodically merged to git.git. Users often send patches
to Junio for these directories when they should be directed at the
current maintainer instead, so we should point out these special
cases in the SubmittingPatches documentation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Just a suggestion. Might help people who are new to the Git
community to get involved.
Documentation/SubmittingPatches | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index de08d09..b7c886c 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -34,10 +34,16 @@ Checklist (and a short version for the impatient):
- if your name is not writable in ASCII, make sure that
you send off a message in the correct encoding.
- send the patch to the list (git@vger.kernel.org) and the
- maintainer (gitster@pobox.com). If you use
+ active maintainer (see below). If you use
git-send-email(1), please test it first by sending
email to yourself.
+ Active maintainers:
+
+ - git-gui/ submodule: spearce@spearce.org
+ - gitk-git/ submodule: paulus@samba.org
+ - Everything else: gitster@pobox.com
+
Long version:
I started reading over the SubmittingPatches document for Linux
--
1.5.4.rc2.1097.gb6e0d
^ permalink raw reply related
* [ANNOUNCE] GIT 1.5.4-rc2
From: Junio C Hamano @ 2007-12-27 3:36 UTC (permalink / raw)
To: git
GIT 1.5.4-rc2 is available at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.4.rc2.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.4.rc2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.4.rc2.tar.{gz,bz2} (preformatted docs)
testing/*-1.5.4.rc2-1.*.rpm (RPM)
This round we still did not manage to keep non-fixes out, and
you can now tell "git commit" to keep the "# comment" lines in
the message, but otherwise the changes are all fixes, fixes and
fixes.
----------------------------------------------------------------
Changes since v1.5.4-rc1 are as follows:
Alex Riesen (1):
Allow selection of different cleanup modes for commit messages
Arjen Laarhoven (1):
Fix "git log --diff-filter" bug
Charles Bailey (1):
Remove old generated files from .gitignore.
Gustaf Hendeby (2):
Make git send-email accept $EDITOR with arguments
shortlog manpage documentation: work around asciidoc markup issues
Jakub Narebski (1):
gitweb: fix whitespace in config_to_multi (indent with tab)
Jeff King (2):
clean up 1.5.4 release notes
cvsimport: die on cvsps errors
Jim Meyering (1):
Don't dereference NULL upon lookup failure.
Johannes Schindelin (2):
Teach diff machinery to display other prefixes than "a/" and "b/"
Mention git-shell's "cvs" substitution in the RelNotes
Junio C Hamano (14):
t4024: fix test script to use simpler sed pattern
fix git commit --amend -m "new message"
shell-scripts usage(): consistently exit with non-zero
Documentation: ls-files -v is about "assume unchanged".
Fix $EDITOR regression introduced by rewrite in C.
t7005: do not exit inside test.
builtin-commit: fix amending of the initial commit
builtin-commit: avoid double-negation in the code.
Documentation: describe 'union' low-level merge driver
Fix documentation of --first-parent in git-log and copy it to git-rev-list
combine-diff: Fix path quoting
Fix rewrite_diff() name quoting.
contrib: resurrect scripted git-revert.
GIT 1.5.4-rc2
Linus Torvalds (1):
Re(-re)*fix trim_common_tail()
Miklos Vajna (1):
everyday: replace 'prune' and 'repack' with 'gc'
Pierre Habouzit (3):
git-tag: fix -l switch handling regression.
Force the sticked form for options with optional arguments.
parse-options: Add a gitcli(5) man page.
René Scharfe (1):
Make "--pretty=format" parser a bit more careful.
Shawn O. Pearce (2):
Reallow git-rebase --interactive --continue if commit is unnecessary
Improve error messages when int/long cannot be parsed from config
Stefan Sperling (1):
Small comment fix for git-cvsimport.
Wincent Colaiuta (1):
Emit helpful status for accidental "git stash" save
^ 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