* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-12 1:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John M. Dlugosz, git
In-Reply-To: <7vprgnlf3f.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 11, 2009 at 9:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> http://article.gmane.org/gmane.comp.version-control.git/54822/
>
> I do not think the description of remote-tracking in that article is
> correct. We use the word to call remote/origin/<name> that keeps copies
> of what we saw over there when we last observed.
>
> The way to mark local branches to merge with/rebase onto something else
> by default is --track option to "git branch" and "git checkout -b", and
> that is often used to mark them to --track remote-tracking branches but
> they do not have to --track remote-tracking branches. They can --track
> local branches as well.
Yes, I noticed this as I re-read the thread. --track and --no-track
are unfortunately poorly named, but that's ancient history. I've
summarized the thread just before you sent this message. I'll update
my summary to note this point. :-)
j.
^ permalink raw reply
* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-12 1:14 UTC (permalink / raw)
To: John M. Dlugosz; +Cc: git
In-Reply-To: <76718490903111758l4e4bd29et379e975deb8e99bd@mail.gmail.com>
On Wed, Mar 11, 2009 at 8:58 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> http://article.gmane.org/gmane.comp.version-control.git/54822/
Let me summarize that thread as best I can.
- The branches under refs/remotes (those shown by "git branch -r") are
remote tracking branches. This is because they typically match (i.e.
track) the corresponding branch on a remote.
- The branches under refs/heads (those shown by "git branch") are your
local branches.
- Local branches can be associated with remote tracking branches in
the repo's config (.git/config). This association is done
automatically in current git when creating a new local branch based on
a remote tracking branch (e.g, git checkout -b topic origin/master or
git branch topic origin/master). (You can use --track and --no-track
to be explicit about whether or not you want the association to
happen.)
The association itself is simply an entry in the repo's .git/config. e.g.:
[branch "topic"]
remote = origin
merge = refs/heads/master
So, what does this entry in the .git/config do for you? A number of things:
1) git branch -v, git status, and git checkout will tell you how far
ahead/behind the local branch is from the associated remote tracking
branch.
2) git fetch, w/o arguments, will look in the config, find the remote
for the currently checked out branch, and update the configured
remote-tracking branches for said remote. This requires a bit more
explanation. In the above example, while topic is checked out, git
fetch will find that the associated remote is called "origin". It will
then update origin per its configuration, also in .git/config. e.g.:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
So that tells git fetch where to fetch from, which remote branches to
fetch, and where to store those branches locally. In this case, each
branch under refs/heads/ on git://git.kernel.org/pub/scm/git/git.git
will be fetched and stored locally as refs/remotes/origin/. Locally
the branches are called "remote tracking branches".
3) git pull, w/o arguments, will run git fetch per above. It then
knows (in this example) to merge refs/remotes/origin/master into
refs/heads/topic. (The value on the "merge =" line is arguably
confusing because it is relative to where the branch is stored on the
remote, not where it is stored locally.)
HTH,
j.
^ permalink raw reply
* Re: setting up tracking on push
From: Junio C Hamano @ 2009-03-12 1:11 UTC (permalink / raw)
To: Jay Soffian; +Cc: John M. Dlugosz, git
In-Reply-To: <76718490903111758l4e4bd29et379e975deb8e99bd@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Wed, Mar 11, 2009 at 8:08 PM, John M. Dlugosz
> <ngnr63q02@sneakemail.com> wrote:
>> On a related note, what exactly does "tracking" mean? I know that I can
>> push/pull local names that match up with names on the origin, and that the
>> latter are in the remotes/origin subdirectory. Those are what I think are
>> called "remote tracking branches". Or is that just a part of the whole
>> story? What is the correct nomenclature?
>
> http://article.gmane.org/gmane.comp.version-control.git/54822/
I do not think the description of remote-tracking in that article is
correct. We use the word to call remote/origin/<name> that keeps copies
of what we saw over there when we last observed.
The way to mark local branches to merge with/rebase onto something else
by default is --track option to "git branch" and "git checkout -b", and
that is often used to mark them to --track remote-tracking branches but
they do not have to --track remote-tracking branches. They can --track
local branches as well.
^ permalink raw reply
* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-12 0:58 UTC (permalink / raw)
To: John M. Dlugosz; +Cc: git
In-Reply-To: <gp9jp7$uc3$1@ger.gmane.org>
On Wed, Mar 11, 2009 at 8:08 PM, John M. Dlugosz
<ngnr63q02@sneakemail.com> wrote:
> On a related note, what exactly does "tracking" mean? I know that I can
> push/pull local names that match up with names on the origin, and that the
> latter are in the remotes/origin subdirectory. Those are what I think are
> called "remote tracking branches". Or is that just a part of the whole
> story? What is the correct nomenclature?
http://article.gmane.org/gmane.comp.version-control.git/54822/
j.
^ permalink raw reply
* Re: [PATCH] allow guilt to handle binary files
From: Josef 'Jeff' Sipek @ 2009-03-12 0:47 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87vdqpuzj5.wl@mail2.atmark-techno.com>
On Wed, Mar 04, 2009 at 11:19:32PM +0900, Yasushi SHOJI wrote:
> git plumbings has been working with binary diff for a while. this one
> liner enable guilt to use those capabilities.
>
> Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
> ---
> Hi Jeff,
>
> I just found out that guilt does not yet support binary patch
> capability git has for a while.
>
> so, before I leave my office, I just tried guilt with this one liner.
> the result was:
>
> - my local test with biniary files work (pop/push was check with md5), and
> - all regression test completed without any error
>
> I felt that I just send it out. :-)
That's how it works :)
> # Note: I've googled "guilt bianry" before sending this but could not
> # find any. I'm not following nether git nor guilt development for a
> # while. so, let me know if I'm off track.
Sorry for taking so long...the patch looks fine. I applied it & pushed it
out.
I think it would be a good idea to have a regression test that specifically
checks binary file handling. I'm not going to get to write it for a couple
of days at least, so feel free to give it a shot :)
Thanks!
Josef 'Jeff' Sipek.
--
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like
that.
- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2] New config push.default to decide default behavior for push
From: Junio C Hamano @ 2009-03-12 0:48 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20090311220144.GA6782@pvv.org>
Finn Arne Gangstad <finnag@pvv.org> writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index f5152c5..6fdf829 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1160,6 +1160,25 @@ pull.octopus::
> pull.twohead::
> The default merge strategy to use when pulling a single branch.
>
> +push.default::
> + Defines the action git push should take if no refspec is given
> + on the command line, no refspec is configured in the remote, and
> + no refspec is implied by any of the options given on the command
> + line.
> +
> + The term `current remote` means the remote configured for the current
> + branch, or `origin` if no remote is configured. `origin` is also used
> + if you are not on any branch.
> +
> + Possible values are:
> ++
> +* `nothing` do not push anything.
> +* `matching` push all matching branches to the current remote.
> + All branches having the same name in both ends are considered to be
> + matching. This is the current default value.
> +* `tracking` push the current branch to whatever it is tracking.
> +* `current` push the current branch to a branch of the same name.
> +
I thought I fixed asciidoc formatting around this part in the version I
queued in 'pu'; in any case, the second and subsequent paragraphs need
dedenting.
> +static void warn_unconfigured_push()
> +{
I think I also fixed this "old style declaration".
> +static void do_default_push(struct remote *remote)
> +{
> + git_config(git_default_config, NULL);
> + switch (push_default) {
> + case PUSH_DEFAULT_UNSPECIFIED:
> + warn_unconfigured_push();
> + /* fallthrough */
> +
> + case PUSH_DEFAULT_MATCHING:
> + add_refspec(":");
> + break;
> +
> + case PUSH_DEFAULT_TRACKING:
> + setup_push_tracking(remote);
> + break;
> +
> + case PUSH_DEFAULT_CURRENT:
> + add_refspec("HEAD");
> + break;
> +
> + case PUSH_DEFAULT_NOTHING:
> + die("Nothing to push, and push is configured to push nothing "
> + "by default.");
> + break;
> + }
> +}
This part looks good, provided if we were to go ahead and plan to change
the default in the future.
> +static void setup_push_tracking(struct remote *remote)
> +{
> + int n;
> + struct branch *branch = branch_get(NULL);
> + if (!branch)
> + die("You are not currently on a branch.");
> + if (!branch->merge_nr)
> + die("The current branch %s is not tracking anything.",
> + branch->name);
> + if (branch->remote != remote)
> + die("The current branch is tracking \"%s\", not \"%s\"!",
> + branch->remote->name, remote->name);
> + for (n = 0; n < branch->merge_nr; n++) {
> + struct strbuf rs = STRBUF_INIT;
> + strbuf_addf(&rs, "%s:%s", branch->name, branch->merge[n]->src);
> + add_refspec(rs.buf);
> + }
> +}
If a branch is configured to merge from multiple places (e.g. testing
branch similar to the linux-next tree to integrate from multiple staging
trees), a sane default would be not to push it out to any of the branches
it pulls from---it is a consumer to the other branches, and it is meant to
be sent to somewhere else, not back to any of the originators. Instead,
this code will push to all of them, which I would not see any sane use
case for. It might make a bit sense if you refused unless merge_nr is
exactly one.
Also I am not sure if the check between the name of the remote makes much
practical sense. Many people use two remotes to name the same one for
pushing over ssh and fetching over git. Which name comes in which? I
think with this logic you are trying to catch a mistake like:
$ git push --tracking $there
when the current branch tracks a remote branch that did not come from the
remote repository $there but somewhere else, but if that is the motivation
behind it, does it help to forbid "push --tracking" to take any
destination repository to reduce such a confusion?
^ permalink raw reply
* Re: setting up tracking on push
From: John M. Dlugosz @ 2009-03-12 0:08 UTC (permalink / raw)
To: git
In-Reply-To: <buofxhr2vta.fsf@dhlpc061.dev.necel.com>
On a related note, what exactly does "tracking" mean? I know that I can push/pull local
names that match up with names on the origin, and that the latter are in the
remotes/origin subdirectory. Those are what I think are called "remote tracking
branches". Or is that just a part of the whole story? What is the correct nomenclature?
--John
^ permalink raw reply
* [PATCH] Documentation: filter-branch: show --ignore-unmatch in main index-filter example
From: Thomas Rast @ 2009-03-11 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Rearrange the example usage of
git filter-branch --index-filter 'git rm --cached ...'
so that --ignore-unmatch is in the main example block. People keep
stumbling over the (lack of this) option to the point where it is a
FAQ, so we would want to expose the most common usage where it stands
out.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
This actually came up once again on IRC about a week ago, but the doc
change sank somewhere deep into my todo stack.
Arguably the --tree-filter 'rm filename' example should get the same
treatment, but I can't find a nice way to do so without harming the
flow of thought in the example development.
Documentation/git-filter-branch.txt | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 7ffe03f..237f85e 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -91,7 +91,9 @@ OPTIONS
--index-filter <command>::
This is the filter for rewriting the index. It is similar to the
tree filter but does not check out the tree, which makes it much
- faster. For hairy cases, see linkgit:git-update-index[1].
+ faster. Frequently used with `git rm \--cached
+ \--ignore-unmatch ...`, see EXAMPLES below. For hairy
+ cases, see linkgit:git-update-index[1].
--parent-filter <command>::
This is the filter for rewriting the commit's parent list.
@@ -204,19 +206,18 @@ However, if the file is absent from the tree of some commit,
a simple `rm filename` will fail for that tree and commit.
Thus you may instead want to use `rm -f filename` as the script.
-A significantly faster version:
+Using `\--index-filter` with 'git-rm' yields a significantly faster
+version. Like with using `rm filename`, `git rm --cached filename`
+will fail if the file is absent from the tree of a commit. If you
+want to "completely forget" a file, it does not matter when it entered
+history, so we also add `\--ignore-unmatch`:
--------------------------------------------------------------------------
-git filter-branch --index-filter 'git rm --cached filename' HEAD
+git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD
--------------------------------------------------------------------------
Now, you will get the rewritten history saved in HEAD.
-As with using `rm filename`, `git rm --cached filename` will fail
-if the file is absent from the tree of a commit. If it is not important
-whether the file is already absent from the tree, you can use
-`git rm --cached --ignore-unmatch filename` instead.
-
To rewrite the repository to look as if `foodir/` had been its project
root, and discard all other history:
--
1.6.2.489.g51f6b7
^ permalink raw reply related
* Re: [PATCH] Include log_config module in apache.conf
From: Jay Soffian @ 2009-03-11 22:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Johannes Schindelin, Daniel Barkalow, git
In-Reply-To: <7vhc1z4y31.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 11, 2009 at 4:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
> We have PidFile definition in the file already, and we have added
> necessary LoadModule for log_config_module recently.
>
> This patch will end up giving LockFile to everybody not just limited to
> Darwin, but why not?
In that case, the -DDarwin added to lib-httpd.sh by commit 69707d61 is
no longer needed.
j.
^ permalink raw reply
* [PATCH] send-email: test --no-thread --in-reply-to combination
From: Thomas Rast @ 2009-03-11 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200903112337.36799.trast@student.ethz.ch>
3e0c4ff (send-email: respect in-reply-to regardless of threading,
2009-03-01) fixed the handling of the In-Reply-To header when both
--no-thread and --in-reply-to are in effect. Add a test for it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t9001-send-email.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 08d5b91..a46f747 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -531,4 +531,15 @@ test_expect_success 'feed two files' '
test "z$(sed -n -e 2p subjects)" = "zSubject: [PATCH 2/2] add master"
'
+test_expect_success 'in-reply-to but no threading' '
+ git send-email \
+ --dry-run \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ --in-reply-to="<in-reply-id@example.com>" \
+ --no-thread \
+ $patches |
+ grep "In-Reply-To: <in-reply-id@example.com>"
+'
+
test_done
--
1.6.2.489.g51f6b7
^ permalink raw reply related
* Re: What's cooking in git.git (Mar 2009, #03; Wed, 11)
From: Thomas Rast @ 2009-03-11 22:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdqg5s17.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
Junio C Hamano wrote:
> * tr/gcov (Thu Feb 19 12:13:42 2009 +0100) 8 commits
> + Test git-patch-id
> + Test rev-list --parents/--children
> + Test log --decorate
> + Test fsck a bit harder
> + Test log --graph
> + Test diff --dirstat functionality
> + Test that diff can read from stdin
> + Support coverage testing with GCC/gcov
>
> * tr/maint-1.6.0-send-email-irt (Sun Mar 1 23:45:41 2009 +0100) 1 commit
> + send-email: respect in-reply-to regardless of threading
>
> Tests?
I see you got tired of waiting while I was out drowning in work, so:
thanks, especially for fixing up the fsck test!
I'll follow up with a test for the latter topic shortly.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [EGIT RFC PATCH(was Re: egit problem with sym linked eclipse project dirs)] Add some support for symlinked projects.
From: Robin Rosenberg @ 2009-03-11 22:17 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: Shawn O. Pearce, git
In-Reply-To: <200901232233.59232.robin.rosenberg.lists@dewire.com>
If a project is not in therepository via the path we found it, we look for its canonical path and
see if that path is in the repository.
We only do this lookup at the project level. Odd linking at resource level
will not be recognized because this lookup is expensive.
---
.../egit/core/project/RepositoryMapping.java | 54 ++++++++++++++++++-
1 files changed, 51 insertions(+), 3 deletions(-)
fredag 23 januari 2009 22:33:59 skrev Robin Rosenberg <robin.rosenberg.lists@dewire.com>:
> fredag 23 januari 2009 02:56:16 skrev Stephen Bannasch:
> > At 6:27 PM -0500 1/13/09, Stephen Bannasch wrote:
> ...
> > >Done: http://code.google.com/p/egit/issues/detail?id=52
> > >
> > >Fxing this will make using Eclipse and Git together SO much nicer!
Since I started looking at this, I may as well post what I came up with before
I lost interest in the issue.
This patch solved some of the problem. I'm not sure it doesn't cause more
problem than it solves, e.g. should the solution support more fine grained
handling of links, be faster or..
Shawn: don't push in this state.
Stephen: come up with a test suite and pro's cons, potholes etc.
-- robin
diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java b/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java
index e9df630..f2a0977 100644
--- a/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java
+++ b/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java
@@ -23,6 +23,7 @@
import org.eclipse.core.runtime.IPath;
import org.eclipse.core.runtime.Path;
import org.eclipse.team.core.RepositoryProvider;
+import org.spearce.egit.core.Activator;
import org.spearce.egit.core.GitProvider;
import org.spearce.jgit.lib.Constants;
import org.spearce.jgit.lib.GitIndex;
@@ -49,6 +50,10 @@ static boolean isInitialKey(final String key) {
private IContainer container;
+ private String replace;
+
+ private String replaceWith;
+
/**
* Construct a {@link RepositoryMapping} for a previously connected project.
*
@@ -97,6 +102,45 @@ public RepositoryMapping(final IContainer mappedContainer, final File gitDir) {
}
}
+ private void checkIsLinked() {
+ File containerFile = container.getLocation().toFile();
+ String absoluteContainer = containerFile.getAbsoluteFile().getPath();
+ String canonicalContainer;
+ try {
+ canonicalContainer = containerFile.getCanonicalFile().getPath();
+ if (!absoluteContainer.equals(canonicalContainer)) {
+ int ic = canonicalContainer.length() - 1;
+ int ac = absoluteContainer.length() - 1;
+ char lastCh = File.separatorChar;
+ while (ic >= 0 && ac >= 0) {
+ char curchar = canonicalContainer.charAt(ic);
+ if (curchar != absoluteContainer.charAt(ac)) {
+ if (lastCh == File.separatorChar) {
+ String linkPointSrc = absoluteContainer.substring(
+ 0, ac + 1);
+ String linkPointDest = canonicalContainer
+ .substring(workdirPrefix.length(), ic + 1);
+ replace = linkPointSrc.substring(
+ workdirPrefix.length()).replace(
+ File.separatorChar, '/');
+ replaceWith = linkPointDest.replace(
+ File.separatorChar, '/');
+ break;
+ }
+ }
+ lastCh = curchar;
+ ic--;
+ ac--;
+ }
+ if (ic == 0 || ac == 0)
+ Activator.logError(String.format("Cannot find the canonical location of %s within the repo %s", containerFile.toString(), gitdirPath), null);
+
+ }
+ } catch (IOException e) {
+ Activator.logError("Cannot get canonical path for container " + container.toString(), e);
+ }
+ }
+
IPath getContainerPath() {
return Path.fromPortableString(containerPath);
}
@@ -136,6 +180,7 @@ synchronized void setRepository(final Repository r) {
workdirPrefix = workdirPrefix.replace('\\', '/');
if (!workdirPrefix.endsWith("/"))
workdirPrefix += "/";
+ checkIsLinked();
}
/**
@@ -209,9 +254,12 @@ public String getRepoRelativePath(final IResource rsrc) {
final int pfxLen = workdirPrefix.length();
final String p = rsrc.getLocation().toString();
final int pLen = p.length();
- if (pLen > pfxLen)
+ if (pLen > pfxLen) {
+ if (replace != null) {
+ return replaceWith + "/" + p.substring(pfxLen + replace.length() + 1);
+ }
return p.substring(pfxLen);
- else if (p.length() == pfxLen - 1)
+ } else if (p.length() == pfxLen - 1)
return "";
return null;
}
--
1.6.1.285.g35d8b
^ permalink raw reply related
* Re: Generalised bisection
From: Ealdwulf Wuffinga @ 2009-03-11 22:15 UTC (permalink / raw)
To: John Tapsell; +Cc: Christian Couder, Git List, Ingo Molnar
In-Reply-To: <43d8ce650903110235q5e2a59f6t201d5e65a4937476@mail.gmail.com>
[John will get this twice, sorry; not used to this mail interface yet.]
On Wed, Mar 11, 2009 at 9:35 AM, John Tapsell <johnflux@gmail.com> wrote:
> mpmath might be the more annoying dependency - what functions do you
> use from it? Could they trivially be reimplemented?
What I use is the multiprecision floating point number class. doubles
don't seem to be long enough.
The reason for using mpmath rather than the more widespread GMP (and
its python wrapper gmpy) is that the latter only supports
integer powers, whereas BBChop needs fractional powers.
So, it might be possible to switch to gmpy, or some other widespread
library, by implementing a pow() which supports fractional powers.
I think I only use the normal arithmetic operators, log, and pow, so
in principle those could be reimplemented, to eliminate the dependency
altogether.
It seems a little bit of a waste of time, though.
Ealdwulf
^ permalink raw reply
* Re: Generalised bisection
From: Ealdwulf Wuffinga @ 2009-03-11 22:14 UTC (permalink / raw)
To: John Tapsell; +Cc: Johannes Schindelin, Christian Couder, Git List, Ingo Molnar
In-Reply-To: <43d8ce650903110624t47e37b19n3fc72e3243978200@mail.gmail.com>
[John will get this twice, sorry]
On Wed, Mar 11, 2009 at 1:24 PM, John Tapsell <johnflux@gmail.com> wrote:
> Not
> quite sure how it would fit in though (I'd rather it was called from
> "git bisect" rather than adding another separate git command)
I guess the most obvious route would be to add an option to 'git bisect start'
to specify that it should be used instead of the usual algorithm.
Ealdwulf
^ permalink raw reply
* [PATCH v2] New config push.default to decide default behavior for push
From: Finn Arne Gangstad @ 2009-03-11 22:01 UTC (permalink / raw)
To: git; +Cc: gitster
This is intended to replace fg/push-default, I'll repost some of the missing
parts as other patches.
--8<--
New config push.default to decide default behavior for push
Currently git push will push all matching branches to the current
remote. For some workflows this default is suboptimal, for new users
it is often surprising, and some have found the default behaviour too
easy to trig by accident with unwanted consequences.
Introduce a new configuration variable "push.default" that decides what
action git push should take if no refspecs are given or implied by the
command line arguments or the current remote configuration. If this
variable is unconfigured, display a prominent warning when default
behavior is trigged.
Possible values are:
'nothing' : Push nothing
'matching' : Current default behaviour, push all branches that already exist
in the current remote
'tracking' : Push the current branch to whatever it is tracking
'current' : Push the current branch to a branch of the same name
Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
Documentation/RelNotes-1.6.3.txt | 7 +++
Documentation/config.txt | 19 +++++++++
builtin-push.c | 80 +++++++++++++++++++++++++++++++++++--
cache.h | 9 ++++
config.c | 25 ++++++++++++
environment.c | 1 +
6 files changed, 136 insertions(+), 5 deletions(-)
diff --git a/Documentation/RelNotes-1.6.3.txt b/Documentation/RelNotes-1.6.3.txt
index ee1fddb..3eb6bf0 100644
--- a/Documentation/RelNotes-1.6.3.txt
+++ b/Documentation/RelNotes-1.6.3.txt
@@ -22,6 +22,13 @@ branch pointed at by its HEAD, gets a large warning. You can choose what
should happen upon such a push by setting the configuration variable
receive.denyDeleteCurrent in the receiving repository.
+In a future release, the default of "git push" without further
+arguments may be changed. Currently, it will push all matching
+refspecs to the current remote. A configuration variable push.default
+has been introduced to select the default behaviour. To ease the
+transition, a big warning is issued if this is not configured and a
+git push without arguments is attempted.
+
Updates since v1.6.2
--------------------
diff --git a/Documentation/config.txt b/Documentation/config.txt
index f5152c5..6fdf829 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1160,6 +1160,25 @@ pull.octopus::
pull.twohead::
The default merge strategy to use when pulling a single branch.
+push.default::
+ Defines the action git push should take if no refspec is given
+ on the command line, no refspec is configured in the remote, and
+ no refspec is implied by any of the options given on the command
+ line.
+
+ The term `current remote` means the remote configured for the current
+ branch, or `origin` if no remote is configured. `origin` is also used
+ if you are not on any branch.
+
+ Possible values are:
++
+* `nothing` do not push anything.
+* `matching` push all matching branches to the current remote.
+ All branches having the same name in both ends are considered to be
+ matching. This is the current default value.
+* `tracking` push the current branch to whatever it is tracking.
+* `current` push the current branch to a branch of the same name.
+
receive.fsckObjects::
If it is set to true, git-receive-pack will check all received
objects. It will abort in the case of a malformed object or a
diff --git a/builtin-push.c b/builtin-push.c
index 122fdcf..fa5eabb 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -48,6 +48,75 @@ static void set_refspecs(const char **refs, int nr)
}
}
+static void setup_push_tracking(struct remote *remote)
+{
+ int n;
+ struct branch *branch = branch_get(NULL);
+ if (!branch)
+ die("You are not currently on a branch.");
+ if (!branch->merge_nr)
+ die("The current branch %s is not tracking anything.",
+ branch->name);
+ if (branch->remote != remote)
+ die("The current branch is tracking \"%s\", not \"%s\"!",
+ branch->remote->name, remote->name);
+ for (n = 0; n < branch->merge_nr; n++) {
+ struct strbuf rs = STRBUF_INIT;
+ strbuf_addf(&rs, "%s:%s", branch->name, branch->merge[n]->src);
+ add_refspec(rs.buf);
+ }
+}
+
+static const char *warn_unconfigured_push_msg[] = {
+ "You did not specify any refspecs to push, and the current remote",
+ "has not configured any push refspecs. The default action in this",
+ "case has been to push all matching refspecs, that is, all branches",
+ "that exist both locally and remotely will be updated.",
+ "This default may change in the future.",
+ "",
+ "You can specify what action you want to take in this case, and",
+ "avoid seeing this message again, by configuring 'push.default' to:",
+ " 'nothing' : Do not push anythig",
+ " 'matching' : Push all matching branches (the current default)",
+ " 'tracking' : Push the current branch to whatever it is tracking",
+ " 'current' : Push the current branch",
+ ""
+};
+
+static void warn_unconfigured_push()
+{
+ int i;
+ for (i = 0; i < ARRAY_SIZE(warn_unconfigured_push_msg); i++)
+ warning("%s", warn_unconfigured_push_msg[i]);
+}
+
+static void do_default_push(struct remote *remote)
+{
+ git_config(git_default_config, NULL);
+ switch (push_default) {
+ case PUSH_DEFAULT_UNSPECIFIED:
+ warn_unconfigured_push();
+ /* fallthrough */
+
+ case PUSH_DEFAULT_MATCHING:
+ add_refspec(":");
+ break;
+
+ case PUSH_DEFAULT_TRACKING:
+ setup_push_tracking(remote);
+ break;
+
+ case PUSH_DEFAULT_CURRENT:
+ add_refspec("HEAD");
+ break;
+
+ case PUSH_DEFAULT_NOTHING:
+ die("Nothing to push, and push is configured to push nothing "
+ "by default.");
+ break;
+ }
+}
+
static int do_push(const char *repo, int flags)
{
int i, errs;
@@ -76,11 +145,12 @@ static int do_push(const char *repo, int flags)
return error("--all and --mirror are incompatible");
}
- if (!refspec
- && !(flags & TRANSPORT_PUSH_ALL)
- && remote->push_refspec_nr) {
- refspec = remote->push_refspec;
- refspec_nr = remote->push_refspec_nr;
+ if (!refspec && !(flags & TRANSPORT_PUSH_ALL)) {
+ if (remote->push_refspec_nr) {
+ refspec = remote->push_refspec;
+ refspec_nr = remote->push_refspec_nr;
+ } else if (!(flags & TRANSPORT_PUSH_MIRROR))
+ do_default_push(remote);
}
errs = 0;
for (i = 0; i < remote->url_nr; i++) {
diff --git a/cache.h b/cache.h
index 189151d..df4f117 100644
--- a/cache.h
+++ b/cache.h
@@ -541,8 +541,17 @@ enum rebase_setup_type {
AUTOREBASE_ALWAYS,
};
+enum push_default_type {
+ PUSH_DEFAULT_UNSPECIFIED = -1,
+ PUSH_DEFAULT_NOTHING = 0,
+ PUSH_DEFAULT_MATCHING,
+ PUSH_DEFAULT_TRACKING,
+ PUSH_DEFAULT_CURRENT,
+};
+
extern enum branch_track git_branch_track;
extern enum rebase_setup_type autorebase;
+extern enum push_default_type push_default;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/config.c b/config.c
index 0c8c76f..e36a2b0 100644
--- a/config.c
+++ b/config.c
@@ -565,6 +565,28 @@ static int git_default_branch_config(const char *var, const char *value)
return 0;
}
+static int git_default_push_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "push.default")) {
+ if (!value)
+ return config_error_nonbool(var);
+ else if (!strcmp(value, "nothing"))
+ push_default = PUSH_DEFAULT_NOTHING;
+ else if (!strcmp(value, "matching"))
+ push_default = PUSH_DEFAULT_MATCHING;
+ else if (!strcmp(value, "tracking"))
+ push_default = PUSH_DEFAULT_TRACKING;
+ else if (!strcmp(value, "current"))
+ push_default = PUSH_DEFAULT_CURRENT;
+ else
+ return error("Malformed value for %s", var);
+ return 0;
+ }
+
+ /* Add other config variables here and to Documentation/config.txt. */
+ return 0;
+}
+
static int git_default_mailmap_config(const char *var, const char *value)
{
if (!strcmp(var, "mailmap.file"))
@@ -588,6 +610,9 @@ int git_default_config(const char *var, const char *value, void *dummy)
if (!prefixcmp(var, "branch."))
return git_default_branch_config(var, value);
+ if (!prefixcmp(var, "push."))
+ return git_default_push_config(var, value);
+
if (!prefixcmp(var, "mailmap."))
return git_default_mailmap_config(var, value);
diff --git a/environment.c b/environment.c
index e278bce..4696885 100644
--- a/environment.c
+++ b/environment.c
@@ -42,6 +42,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
+enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;
/* Parallel index stat data preload? */
int core_preload_index = 0;
--
1.6.2.107.ge47ee.dirty
^ permalink raw reply related
* Re: [PATCH] Removed unnecessary use of global variables.
From: Junio C Hamano @ 2009-03-11 22:00 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johannes Schindelin, Erik Faye-Lund, git
In-Reply-To: <20090312064237.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> 1. Are you and Junio one same person, and if so what made you change your mind during these 8 hours ;-)?
Last year during Gittogether, Dscho and I were seen in a room sitting
parhaps 4 meters apart; I suspect we are different people.
http://picasaweb.google.com/dsymonds/GitTogether08#5263025230667494002
> 2. Junio said "ef90d6d (Provide git_config with a callback-data parameter, 2008-05-14)" and yours is slightly different. Both are equally readable but I think it would help to make sure everybody uses the same format within one project. Do we need a helper command that everybody can use?
I use these two aliases while I am writing e-mails quite often:
[alias]
one = "!sh -c 'git show -s --pretty=\"format:%h (%s, %ai\" \"$@\" | sed -e \"s/ [012][0-9]:[0-5][0-9]:[0-5][0-9] [-+][0-9][0-9][0-9][0-9]$/)/\"' -"
who = "!sh -c 'git log -1 --pretty=\"format:%an <%ae>\" --author=\"$1\"' -"
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Junio C Hamano @ 2009-03-11 21:47 UTC (permalink / raw)
To: david; +Cc: Johannes Schindelin, saurabh gupta, git
In-Reply-To: <alpine.DEB.1.10.0903111401520.16753@asgard.lang.hm>
david@lang.hm writes:
>>> there are two types of helpers that can be written
>>>
>>> 1. a low-level part that does the simple merges automaticaly and leaves
>>> behind appropriate conflict markers when it can't
>>>
>>> 2. after a conflict has taken place, a helper to work with the user to
>>> resolve the conflict
> ...
> secondly, I somewhat disagree with you. #1 is needed for any new
> formats that are goning to be handled, but #2 may not be.
>
> take the case of OO documents, you may not need to write a conflict
> resolver helper. the 'appropriate conflict markers' may be something
> that shows up in your normal OO document editor similar to how the
> ====> shows up in a text editor for text conflicts
You can cut it both ways. For an OO document, you do not necessarily need
any file-level merger at the driver level, but just let the "binary"
driver declare conflicts and punt. A merge helper can do all the work
starting from the "original, ours and theirs" that are not smudged with
conflict markers.
Between these two extremes, the discussion from other people in the thread
seemed to all focus too heavily on the "driver punts" approach, forgetting
that mergetool is useful only because most of the time we do not have to
even use it, thanks to the fact that "xdl" driver works reasonably well
for most trivial cases where branches being merged stayed away from each
other, which is the majority case. It is a huge win from the productivity
point of view, and many people might be unaware of it because it is so
invisible.
Handling trivial cases safely and automatically at the driver level, if
you can figure out how, lets the user focus on hard cases that needs
manual intervention, and "merge helper" is about helping that manual
intervention step.
Being aware of these two distinct layers allows you to realize that there
is a third possibility. The driver could notice the cases it can resolve
cleanly and return a cleanly merged result. When it cannot autoresolve,
but there is no way to "mark" a tentative result with conflict markers, it
can do the same thing as the "binary" driver and let the mergetool backend
handle the "driver punted" case.
^ permalink raw reply
* Re: [PATCH] Removed unnecessary use of global variables.
From: Nanako Shiraishi @ 2009-03-11 21:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, git
In-Reply-To: <alpine.DEB.1.00.0903111126280.10279@pacific.mpi-cbg.de>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Wed, 11 Mar 2009, Erik Faye-Lund wrote:
>
>> git_config() now takes a third data-parameter that is passed back
>> to the callback-function. At the time this code was written, that
>> parameter did not exist, so a somewhat nasty (but by all means
>> correct) use of global variables was introduced. In commit
>> ef90d6d4208a5130185b04f06e5f90a5f9959fe3 Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> introduced a parameter for similar
>> purposes.
>
> We tend to quote commits in this form: ef90d6d(Provide git_config with a
> callback-data parameter)
Your review comments are a subset of the ones Junio sent about 8 hours before you did, and are almost identical except for the comment on the subject line yours didn't have. I'm curious about two things.
1. Are you and Junio one same person, and if so what made you change your mind during these 8 hours ;-)?
2. Junio said "ef90d6d (Provide git_config with a callback-data parameter, 2008-05-14)" and yours is slightly different. Both are equally readable but I think it would help to make sure everybody uses the same format within one project. Do we need a helper command that everybody can use?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: setting up tracking on push
From: Marc Branchaud @ 2009-03-11 21:39 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, Jeff King, Miles Bader, git
In-Reply-To: <76718490903102222n23e0e7fdlcee2888333a2b912@mail.gmail.com>
Jay Soffian wrote:
>
> Actually, for me, I find sometimes I've forgotten to setup tracking,
> or I've setup tracking and don't want it. I just fire up an editor on
> .git/config, or use git config, but I would appreciate an easy way to
> add/remove tracking to a branch after the fact.
I second that -- that's the exact situation I ran into.
Editing .git/config is scary and obscurely documented for new users (who are more likely to forget to set up tracking). Plus encapsulating this in some porcelain makes it a bit less error-prone.
M.
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-11 21:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: saurabh gupta, git
In-Reply-To: <alpine.DEB.1.00.0903112136560.10279@pacific.mpi-cbg.de>
On Wed, 11 Mar 2009, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 11 Mar 2009, david@lang.hm wrote:
>
>> there are two types of helpers that can be written
>>
>> 1. a low-level part that does the simple merges automaticaly and leaves
>> behind appropriate conflict markers when it can't
>>
>> [...]
>>
>>
>> 2. after a conflict has taken place, a helper to work with the user to
>> resolve the conflict
>
> I thought that from my description on the wiki it was obvious that both
> are needed.
first off, I'll admit that I am just going by what's been posted here, I
haven't gone looking on the wiki.
secondly, I somewhat disagree with you. #1 is needed for any new formats
that are goning to be handled, but #2 may not be.
take the case of OO documents, you may not need to write a conflict
resolver helper. the 'appropriate conflict markers' may be something that
shows up in your normal OO document editor similar to how the ====> shows
up in a text editor for text conflicts
David Lang
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-11 20:37 UTC (permalink / raw)
To: david; +Cc: saurabh gupta, git
In-Reply-To: <alpine.DEB.1.10.0903111307050.16753@asgard.lang.hm>
Hi,
On Wed, 11 Mar 2009, david@lang.hm wrote:
> there are two types of helpers that can be written
>
> 1. a low-level part that does the simple merges automaticaly and leaves
> behind appropriate conflict markers when it can't
>
> [...]
>
>
> 2. after a conflict has taken place, a helper to work with the user to
> resolve the conflict
I thought that from my description on the wiki it was obvious that both
are needed.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] git push usability improvements and default change
From: Junio C Hamano @ 2009-03-11 20:35 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20090310100400.GC11448@pvv.org>
Finn Arne Gangstad <finnag@pvv.org> writes:
> On Mon, Mar 09, 2009 at 05:07:08PM -0700, Junio C Hamano wrote:
> ...
>> * What's the point of having --current option, when you can already
>> say HEAD, i.e. $ git push origin HEAD
>
> It does something very different. Maybe --tracking would be a better name.
> --current does basically this:
> ...
> The goal here is to be able to:
>
> git checkout -b junios-next origin/next
> git push --current <=> git push origin junios-next:next
>
> git push origin HEAD would do git push origin junios-next:junios-next,
> which was not the intention.
Ok, now that sort of makes sense, and is very different from people would
expect from --current, which I think most people would associate with
HEAD. "tracking" or "track back" would be a better name.
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-11 20:21 UTC (permalink / raw)
To: saurabh gupta; +Cc: Johannes Schindelin, git
In-Reply-To: <ab9fa62a0903111302j46c46c2q96af497fa2ac513e@mail.gmail.com>
On Thu, 12 Mar 2009, saurabh gupta wrote:
> On Thu, Mar 12, 2009 at 12:59 AM, <david@lang.hm> wrote:
>> On Wed, 11 Mar 2009, saurabh gupta wrote:
>>
>>> On Wed, Mar 11, 2009 at 10:02 PM, <david@lang.hm> wrote:
>>>>
>>>> On Wed, 11 Mar 2009, Johannes Schindelin wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, 11 Mar 2009, saurabh gupta wrote:
>>>>>
>>>
>>> In case of only a terminal, It would be very difficult to show an OO
>>> document to represent the *diff* output in both text as well in GUI.
>>> For example, to indicate the changes in an OO document, we will have
>>> to change the underlying XML file appropriately to show the markers
>>> signs and other things in the conflict file. Now, if this file is
>>> opened in terminal, it would not be at all comprehensible to see the
>>> differences.
>>>
>>> The main thing is that to create *diff* for different file formats, we
>>> will have to write the parser code accordingly.
>>
>> correct, and in the case of an XML file, the meaningful diff can be
>> substantially shorter than what a text diff of the two files would be
>> (whitespace changes that don't matter, even some tag ordering changes may
>> not matter)
>>
>> I'm just asking that you don't get so fixated on what can be done in a GUI
>> that you provide no benifit to people who don't have the GUI
>>
>> there are a _lot_ of XML based formats out there, having a diff/merge
>> capability to make dealing with them better than just treating them as text
>> files would be a _very_ useful thing.
>>
>> going beyond that and creating the ability to do the markup in
>> application-specific ways, and present it to the user in a nice GUI would
>> also be nice, but these are a step up after having the basic XML handling
>> that isn't specific to a particular application.
>
> Yes, but the thing is that the underlying codes and method will be
> different for GUI part and terminal part to make it readable and
> understandable. Like for OO Documents, if we aim to show the *diff*
> output in the Office tool, then we have to change the xml file
> accordingly. But the same xml file when used with terminal only, the
> *diff* output is not clear.
>
> As Johannes said in above post that for OO documents, while showing
> the *diff* result, no xml data should be shown.
in part we are talking about different aspects of things, and we were all
wrong.
see the e-mail a little bit ago by Junio
there are two types of helpers that can be written
1. a low-level part that does the simple merges automaticaly and leaves
behind appropriate conflict markers when it can't
there is no GUI involved with this.
what 'appropriate conflict markers' are can vary from XML file to XML file
2. after a conflict has taken place, a helper to work with the user to
resolve the conflict
this can have a GUI and/or a text UI and is tied to the 'appropriate
conflict markers' as defined in #1, and can be _very_ tightly coupled to
the specific use of the XML file.
I think it's very important to have a text UI tool that can be used for
the conflict resolution step as well as supporting GUI tools.
besides XML-based formats, a couple other formats that I think would be
useful to be smarter about
unordered config files
files where config options can appear in any order
optionally: comments are similar to whitespace (they can be ignored)
'paragraph' based config files
files where config options are orginized into 'paragraphs' where the
paragraphs can be re-ordered
the definition of what's a paragraph may differ, support having
different defintions
examples:
the git config file has a high level tag that starts on the left margin with the sub-tags indented
the apache config file can have single entries or 'XML like' sections
optionally: comments are similar to whitespace (they can be ignored)
David Lang
^ permalink raw reply
* Re: [PATCH] Include log_config module in apache.conf
From: Junio C Hamano @ 2009-03-11 20:13 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Johannes Schindelin, Daniel Barkalow, git
In-Reply-To: <E7E9DDFD-F8F6-4B39-A3E3-48CC1C8F5BBC@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> On Mar 11, 2009, at 2:58 PM, Junio C Hamano wrote:
>
>> diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
>> index a0d4077..f460e40 100644
>> --- a/t/lib-httpd/apache.conf
>> +++ b/t/lib-httpd/apache.conf
>> @@ -4,7 +4,9 @@ DocumentRoot www
>> LogFormat "%h %l %u %t \"%r\" %>s %b" common
>> CustomLog access.log common
>> ErrorLog error.log
>> -LoadModule log_config_module modules/mod_log_config.so
>> +<IfModule !mod_log_config.c>
>> + LoadModule log_config_module modules/mod_log_config.so
>> +</IfModule>
>>
>> <IfDefine Darwin>
>> LoadModule log_config_module modules/mod_log_config.so
>
> Isn't this last line redundant now?
<IfDefine Darwin>
LoadModule log_config_module modules/mod_log_config.so
LockFile accept.lock
PidFile httpd.pid
</IfDefine>
I think we can lose the first among these three lines safely, but I wonder
if we can get rid of the Darwin specific part altogether.
-- >8 --
Subject: http tests: Darwin is not that special
We have PidFile definition in the file already, and we have added
necessary LoadModule for log_config_module recently.
This patch will end up giving LockFile to everybody not just limited to
Darwin, but why not?
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/lib-httpd/apache.conf | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index f460e40..6533c2d 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -1,5 +1,6 @@
ServerName dummy
+LockFile accept.lock
PidFile httpd.pid
DocumentRoot www
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog access.log common
@@ -8,12 +9,6 @@ ErrorLog error.log
LoadModule log_config_module modules/mod_log_config.so
</IfModule>
-<IfDefine Darwin>
- LoadModule log_config_module modules/mod_log_config.so
- LockFile accept.lock
- PidFile httpd.pid
-</IfDefine>
-
<IfDefine SSL>
LoadModule ssl_module modules/mod_ssl.so
^ permalink raw reply related
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Alejandro Riveira @ 2009-03-11 20:12 UTC (permalink / raw)
To: git
In-Reply-To: <49B7E670.7060606@drmicha.warpmail.net>
El Wed, 11 Mar 2009 17:27:28 +0100, Michael J Gruber escribió:
> Jay Soffian venit, vidit, dixit 11.03.2009 16:49:
>>
>> j.
>
> FWIW: The effect you describe (which is different from the OP) occurs on
> Fedora 10 as well, and not only for git man pages, also for others. I've
> been meaning to look into this, just like I've been meaning to look into
> so much stuff...
>
"Me too" from a Ubuntu 8.10 Box
> Michael
^ 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