* Re: [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Shawn Pearce @ 2006-11-26 3:02 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611260003.31025.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> If .git/remotes/ is now deprecated, then git-clone shouldn't use it.
> This patch adds the analogous definitions to .git/config using
> git-repo-config calls.
>
> For example what was previously .git/remotes/origin
> URL: proto://host/path
> Pull: refs/heads/master:refs/heads/origin
> Is now added to .git/config as
> [remote "origin"]
> url = proto://host/path
> fetch = refs/heads/master:refs/heads/origin
>
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
> I'm not sure if I'm correct in thinking that .git/remotes is deprecated. If it is,
> this patch makes git-clone use .git/config instead.
>
> Personally I like it, I think there should be as small a number of places for
> configuring the repository as possible.
I agree. There's all sorts of advantages to setting up remotes by
the config file. Its also easier to load and work with in git-gui.
:-)
I've switched to the config file syntax completely, and a few folks
I work with have done the same, citing that it is easier to have
everything in one file.
--
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Shawn Pearce @ 2006-11-26 3:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vvel3yuzz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> > The question is: do we continue to use remotes/ file, or do we
> > save remotes info in the config file: remote.<name>.url,
> > remote.<name>.fetch, remote.<name>.push and branch.<name>.merge
> > (in our case '[remote "origin"]' section)?
>
> It is not "the question"; it is irrelevant because
> $GIT_DIR/remotes/origin and [remote "origin"] are pretty much
> interchangeable, and will hopefully continue to be.
I'm all for:
* changing the default made git-clone to be [remote "<origin>"]
* continuing to support parsing of $GIT_DIR/remotes/*
We moved away from the $GIT_DIR/branches directory to
$GIT_DIR/remotes, yet we still support $GIT_DIR/branches in
remote handling code. I see no reason why we cannot start to use
remote.<name>.url by default while continuing to support the older
branches and remotes formats.
For one thing the newer remote.<name>.fetch seems to make more sense
to new users than Pull: lines do. For another it appears to be
supported since v1.4.0, which was released June 10th. Most users
cloning a repository with >1.4.4.1 will probably only use 1.4.0
or later on that same repository, so there is probably low risk of
breakage due to the remote not being recognized by a pre-1.4.0 Git.
--
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Shawn Pearce @ 2006-11-26 3:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <ekafpm$fs7$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
> > Pull: +refs/heads/*:refs/remotes/<origin>/*
>
> I hope that it also works with the remote.origin config file
> section instead of $GIT_DIR/remotes/origin
Yes, it does. Fortunately Git is relatively consistent. :-)
> > Forcing with '+' is debatable, but with separate-remote layout,
> > remotes/*/ hierarchy is to track what the remote has, and you
> > cannot do much else other than noticing and warning when the
> > remote end does funny things to its refs anyway, so I think
> > having '+' might be a better default.
>
> Perhaps, perhaps not. It would be nice to have configuration option
> that would tell that history of given branch is being changed, and
> the ability to ask about it remotely, so git-clone would be able
> to add this + _when needed_ automatically.
>
> But it's a fact that with separate remote the need to use fast-forward
> check is lessened, and it might be more important to not confuse first
> time user with having to modify $GIT_DIR/remotes/origin or remote.origin
> config section to fetch from the repository he/she cloned from.
Yes. From an out-of-the-box-make-Git-appear-to-be-easier-to-use
point of view tossing + into the Pull:/remote.<name>.fetch setup
might seem like the right thing to do. It lets the end-user blindly
follow the upstream repository they cloned from. Almost.
The problem becomes when the user makes a topic branch off say
Junio's `pu` branch and later after doing a fetch and looking at
the log of `remotes/origin/pu` decide to pull the updated `pu`
into their topic branch, so they can continue testing. But now
they are in merge hell as Junio has completely rebased `pu` and
what was there isn't, and what's there now ain't compatible...
and the new user curses at Git.
Needing to put + in front of a refspec (or needing to fetch it with
--force) is the user agreeing that something _evil_ is going on with
the upstream and that they acknowledge this may cause problems for
them locally.
I would prefer to see the upstream be able to publish a short
description of each branch, where the repository owner can describe
the policy of that branch, as well as have a machine readable
setting on each branch indicating if that branch will be rewound
from time to time, or never rewound.
git-clone should skip rewinding branches by default, unless the user
adds an option (e.g. --include-rewinding-branches). This way new
users to git.git don't get the `pu` branch unless they really mean
to get it, at which point they have hopefully also read the upstream's
description of the `pu` branch and its rewinding policy, and can
at least start to grasp what is going to happen if they start to
work with the branch.
> > I am not sure if 'merge in corresponding branch' is the only
> > valid workflow, however. I am reluctant to make the system
> > automatically do so if the solution makes other workflows more
> > painful to follow. Automatically merging remotes/origin/$foo
> > when on $foo branch is not good enough, in other words (also,
> > there may be a hierarchy under remotes/ other than origin). It
> > might make sense to introduce "Merge: " in remotes/ file and if
> > they are present use "Pull: " only to decide what are fetched
> > and use "Merge: " to decide what is merged (if we were doing the
> > system from scratch, the former would have been named "Fetch: "
> > but it is too late now).
>
> If you add "Merge: " in remotes/, then please add it also in
> remote section in config file. Config file has now
> branch.<branchname>.merge (and it would be nice if clone would
> set ou this for local branches corresponding to remote branches),
> but it is not the same.
I'm against adding anything to the remotes/ file format.
We already have branch.<name>.merge to indicate what the default
source for a git-pull on the branch named <name> should be.
git-branch probably should fill that entry in when a branch is
created from a remotes ref.
--
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Junio C Hamano @ 2006-11-26 3:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611260034.23974.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Well, the question is if git-clone would generate appropriate config
> entries in addition to or instead of $GIT_DIR/remotes/origin file...
What I meant by "irrelevant" is that it is purely syntax. I
would rather nail down the desired semantics first, and then
worry about the syntax. We have done remotes/origin file by
default and allowed the same thing specified in configuration
file for people who prefer configuration file, and I do not see
an immediate need to change that.
Only if/when the desired semantics turns out to be too complex
to be expressed in the remotes/ file scheme and at the same time
if configuration file is easier to express the same information,
we should start talking about favoring configuration file over
remotes/ file, and perhaps generating the config entries by
default without generating remotes/.
In either case, I do not think generating _both_ by default is a
bad idea. They will become out of sync and the user either need
to delete one or the other to avoid confusion.
> By the way, what do you think about extended refspec syntax, namely
> in addition to <remote name>:<local name> it would allow to say
> <remote name>:<local name>:<local branch to merge into>?
I do not think it is reasonable to assume that one remote branch
is to be always merged into one fixed local branch, so that is
too limiting as an extension. In the configuration file, I
think we already allow the default remote to be fetched from and
remote branches to be merged per branch statically. A
reasonable thing to do is to see how satisfied users are with
that facility, what they find missing there. Worrying about the
syntax should wait until we know what kind of things need to be
expressed; that can be done both by extending the existing
configuration and/or introducing a new entries in remotes/
files but the point is that is mere implementation detail.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-11-26 3:39 UTC (permalink / raw)
To: Yann Dirson; +Cc: Steven Grimm, git
In-Reply-To: <20061125234908.GC24909@nan92-1-81-57-214-146.fbx.proxad.net>
On Sun, 26 Nov 2006, Yann Dirson wrote:
>
> Also, I'd rather expect "git-commit -a" outside of any submodule to
> commit everything in the supermodule, triggering submodule commits as an
> intermediate step when needed - just like "git-commit -a" does not
> require to manually specify subdirectories to inclue in the commit. I'd
> rather expect a special flag to exclude submodules from a commit.
So, how do you do commit messages? It generally doesn't make sense to
share the same commit message for submodules - the sub-commits generally
do different things.
I'd actually suggest that "git commit -a" with non-clean submodules error
out for that reason, with something like
submodule 'src/xyzzy' is not up-to-date, please commit changes to
that first.
exactly because you really generally should consider the submodule commits
to be a separate phase.
^ permalink raw reply
* [PATCH] Documentation: clarify tutorial pull/merge discussion
From: J. Bruce Fields @ 2006-11-26 3:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <20061124161144.GA19708@fieldses.org>
Attempt to clarify somewhat the difference between pull and merge,
and give a little more details on the pull syntax.
I'm still not happy with this section: the explanation of the origin
branch isn't great, but maybe that should be left alone pending the
use-separate-remotes change; and we need to explain how to set up a
public repository and push to it.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/tutorial.txt | 41 ++++++++++++++++++++++++++---------------
1 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 1e4ddfb..35af81a 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -209,29 +209,28 @@ at /home/bob/myrepo. She does this with
------------------------------------------------
$ cd /home/alice/project
-$ git pull /home/bob/myrepo
+$ git pull /home/bob/myrepo master
------------------------------------------------
-This actually pulls changes from the branch in Bob's repository named
-"master". Alice could request a different branch by adding the name
-of the branch to the end of the git pull command line.
+This merges the changes from Bob's "master" branch into Alice's
+current branch. If Alice has made her own changes in the meantime,
+then she may need to manually fix any conflicts. (Note that the
+"master" argument in the above command is actually unnecessary, as it
+is the default.)
-This merges Bob's changes into her repository; "git log" will
-now show the new commits. If Alice has made her own changes in the
-meantime, then Bob's changes will be merged in, and she will need to
-manually fix any conflicts.
+The "pull" command thus performs two operations: it fetches changes
+from a remote branch, then merges them into the current branch.
-A more cautious Alice might wish to examine Bob's changes before
-pulling them. She can do this by creating a temporary branch just
-for the purpose of studying Bob's changes:
+You can perform the first operation alone using the "git fetch"
+command. For example, Alice could create a temporary branch just to
+track Bob's changes, without merging them with her own, using:
-------------------------------------
$ git fetch /home/bob/myrepo master:bob-incoming
-------------------------------------
which fetches the changes from Bob's master branch into a new branch
-named bob-incoming. (Unlike git pull, git fetch just fetches a copy
-of Bob's line of development without doing any merging). Then
+named bob-incoming. Then
-------------------------------------
$ git log -p master..bob-incoming
@@ -240,8 +239,8 @@ $ git log -p master..bob-incoming
shows a list of all the changes that Bob made since he branched from
Alice's master branch.
-After examining those changes, and possibly fixing things, Alice can
-pull the changes into her master branch:
+After examining those changes, and possibly fixing things, Alice
+could pull the changes into her master branch:
-------------------------------------
$ git checkout master
@@ -251,6 +250,18 @@ $ git pull . bob-incoming
The last command is a pull from the "bob-incoming" branch in Alice's
own repository.
+Alice could also perform both steps at once with:
+
+-------------------------------------
+$ git pull /home/bob/myrepo master:bob-incoming
+-------------------------------------
+
+This is just like the "git pull /home/bob/myrepo master" that we saw
+before, except that it also stores the unmerged changes from bob's
+master branch in bob-incoming before merging them into Alice's
+current branch. Note that git pull always merges into the current
+branch, regardless of what else is given on the commandline.
+
Later, Bob can update his repo with Alice's latest changes using
-------------------------------------
--
1.4.4.rc1.g83ee9
^ permalink raw reply related
* Re: [RFD] making separate-remote layout easier to use
From: Junio C Hamano @ 2006-11-26 3:48 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061126031421.GC29394@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> We moved away from the $GIT_DIR/branches directory to
> $GIT_DIR/remotes, yet we still support $GIT_DIR/branches in
> remote handling code.
IIRC, git never used "branches", so there was no "moving away".
It was merely to interpret what cg-init left in the repository.
Since the very early days remotes/ has been _the_ format git
used, and I do not see any strong reason to change it now. The
continued support for branches is an irrelevant topic and is not
a justification to favor configuration over remotes/ nor the
other way around.
> For one thing the newer remote.<name>.fetch seems to make more sense
> to new users than Pull: lines do.
That is quite subjective.
> ..., so there is probably low risk of
> breakage ...
Again, "low risk of breakage" does not justify switching.
As I said in the other message, I think configuration vs remotes/
is futile subject and premature topic to talk about before
nailing down what semantics we would want. Either format can
have the expressive power, once we know what we want to express.
^ permalink raw reply
* Re: [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Junio C Hamano @ 2006-11-26 3:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611260141390.30004@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_
> remoter.bla.fetch. To avoid that, you have to use "git repo-config
> remote.bla.fetch b ^$". (The last argument is a regular expression which
> has to be matched by the value-to-be-oreplaced.)
Yup, one of the joys of working the config file everybody seems
to like ;-).
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Junio C Hamano @ 2006-11-26 3:58 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061126033433.GD29394@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Needing to put + in front of a refspec (or needing to fetch it with
> --force) is the user agreeing that something _evil_ is going on with
> the upstream and that they acknowledge this may cause problems for
> them locally.
>
> I would prefer to see the upstream be able to publish a short
> description of each branch, where the repository owner can describe
> the policy of that branch, as well as have a machine readable
> setting on each branch indicating if that branch will be rewound
> from time to time, or never rewound.
>
> git-clone should skip rewinding branches by default, unless the user
> adds an option (e.g. --include-rewinding-branches). This way new
> users to git.git don't get the `pu` branch unless they really mean
> to get it, at which point they have hopefully also read the upstream's
> description of the `pu` branch and its rewinding policy, and can
> at least start to grasp what is going to happen if they start to
> work with the branch.
I like this approach very much.
^ permalink raw reply
* [PATCH] Documentation: add a "git user's manual"
From: J. Bruce Fields @ 2006-11-26 4:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, linux, git
In-Reply-To: <20061119175040.GB15608@fieldses.org>
On Sun, Nov 19, 2006 at 12:50:40PM -0500, J. Bruce Fields wrote:
> In fact, I'm tempted to submit a patch that just assigns a chapter
> number to everything under Documentation/, slaps a single table of
> contents on the front, and calls the result "the git user's manual."
Something like this, as a start?:
Add a manual.txt file which generates a "git user's manual" by including
a bunch of preexisting files under Documentation and declaring each to
be a chapter.
The result is a disorganized mess, because the documentation itself is a
disorganized mess. This is intended to call attention to that fact
rather than fix it. Hopefully we can massage it into a better order
over time. And hopefully we can encourage anyone that adds new
documentation to think about where in the order it should be inserted.
Not built or installed by default for now.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/Makefile | 7 ++++++-
Documentation/manual.conf | 2 ++
Documentation/manual.txt | 30 ++++++++++++++++++++++++++++++
3 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index c00f5f6..684dacf 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -85,9 +85,14 @@ clean:
%.1 %.7 : %.xml
xmlto -m callouts.xsl man $<
-%.xml : %.txt
+%.html : %.txt
asciidoc -b docbook -d manpage -f asciidoc.conf $<
+manual.html: manual.txt
+ a2x -f xhtml --no-icons --asciidoc-opts="-d book -f asciidoc.conf" $<
+
+# a2x -f xhtml --ascidoc-opts="-d book -f asciidoc.conf" $<
+
git.html: git.txt README
glossary.html : glossary.txt sort_glossary.pl
diff --git a/Documentation/manual.conf b/Documentation/manual.conf
new file mode 100644
index 0000000..0d0cfad
--- /dev/null
+++ b/Documentation/manual.conf
@@ -0,0 +1,2 @@
+[titles]
+underlines="__","==","--","~~","^^"
diff --git a/Documentation/manual.txt b/Documentation/manual.txt
new file mode 100644
index 0000000..5512212
--- /dev/null
+++ b/Documentation/manual.txt
@@ -0,0 +1,30 @@
+Git User's manual
+_________________
+
+include::tutorial.txt[]
+
+include::tutorial-2.txt[]
+
+Git design overview
+===================
+
+include::README[]
+
+include::everyday.txt[]
+
+include::cvs-migration.txt[]
+
+include::howto-index.txt[]
+
+include::hooks.txt[]
+
+include::diffcore.txt[]
+
+include::repository-layout.txt[]
+
+include::core-tutorial.txt[]
+
+Glossary of git terms
+=====================
+
+include::glossary.txt[]
--
1.4.4.rc1.g83ee9
^ permalink raw reply related
* Re: Calling all bash completion experts..
From: Shawn Pearce @ 2006-11-26 4:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0611251106250.6991@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
> On Sat, 25 Nov 2006, Shawn Pearce wrote:
> >
> > I added the nospace option because of the completion for fetch/push,
> > cat-file, diff-tree and ls-tree.
> >
> > The problem is the file completion for e.g. cat-file. We don't
> > want a space added after we complete a directory name, so you can
> > complete further, e.g.:
> >
> > git cat-file -p ma<tab>con<tab>comp<tab>git-com<tab>
>
> But that's how directory completion _always_ works. Completion doesn't add
> spaces to directories anyway, it adds a "/".
>
> The branch-name thing is well-taken: you don't want to add a space after a
> branch-name, although neither do you want to add a ":" by default.
>
> So "nospace" after a branch (or tag) name sounds sane, but nowhere else
> that I can see.
All in all what you are asking is reasonable. Users really should
expect the Git completion to work just like any other completion
built-in to bash. I've just run into some difficulty making that
be the case with all of the git commands. :)
I'm trying to push really hard on git-gui right now, to get it to
the point that people who are absolutely terrified of the command
line can still do basic operations (commit, fetch, trivial merge,
push). 'cause I really need to get a some of those users onto
a git repository (like everyone else) rather than an unbacked-up
network share which has no revision history.
I'll come back to the bash completion soon. Jakub Narebski and
another person have both asked that I do some more work for other
commands. I was hoping that other person might do some of the
modifications himself and contribute them back, but it looks like
he's just as busy as I am and hasn't found the time.
--
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Shawn Pearce @ 2006-11-26 4:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvel2yi2u.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Needing to put + in front of a refspec (or needing to fetch it with
> > --force) is the user agreeing that something _evil_ is going on with
> > the upstream and that they acknowledge this may cause problems for
> > them locally.
> >
> > I would prefer to see the upstream be able to publish a short
> > description of each branch, where the repository owner can describe
> > the policy of that branch, as well as have a machine readable
> > setting on each branch indicating if that branch will be rewound
> > from time to time, or never rewound.
> >
> > git-clone should skip rewinding branches by default, unless the user
> > adds an option (e.g. --include-rewinding-branches). This way new
> > users to git.git don't get the `pu` branch unless they really mean
> > to get it, at which point they have hopefully also read the upstream's
> > description of the `pu` branch and its rewinding policy, and can
> > at least start to grasp what is going to happen if they start to
> > work with the branch.
>
> I like this approach very much.
I think the idea of glob'ing off the remote during clone (and
using the glob for future fetches) is a good idea. So I think what
I'm suggesting above is to make glob'ing by default not copy the
rewinding branches, unless the glob spec itself starts with '+'
(which is what say --include-rewriting-branches would do).
So now we're at a point of:
* how do we get this branch information from the remote?
* how does the remote store this branch information?
I'm leaning towards the repo config for the latter, with say:
[branch "pu"]
rewinds = true
description = This branch contains some proposed updates to git.\n\
It rewinds often, as different updates are proposed or merged into 'next'.
but looking at that think its rather horrible looking. :-)
However for the former it may be useful if the client can download
the repo config from the remote repository, such as to fetch
the branch description data.
--
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Junio C Hamano @ 2006-11-26 5:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061126042311.GB30001@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> So now we're at a point of:
>
> * how do we get this branch information from the remote?
> * how does the remote store this branch information?
>
> I'm leaning towards the repo config for the latter, with say:
>
> [branch "pu"]
> rewinds = true
> description = This branch contains some proposed updates to git.\n\
> It rewinds often, as different updates are proposed or merged into 'next'.
>
> but looking at that think its rather horrible looking. :-)
>
> However for the former it may be useful if the client can download
> the repo config from the remote repository, such as to fetch
> the branch description data.
For the former, I was hoping that we could do a new action
against remote repository that is "get remote information". Just
like we have "ls-remote" as a protocol neutral front-end to get
what git native protocol would give "peek-remote", git native
protocol would have get-repository-info action to transfer this
information, and http and dumb transports do a file download
from a known file, just like they download files prepared with
update-server-info. Most likely, that get-repository-info is
just a glorified single file transfer and nothing more.
As an implementation detail, I think it is one possibility to
store this information in the config of the repository being
cloned from. We should be able to use repo-config to
parse that file in config-like syntax to extract what we would
want, so we do not have to come up with a new syntax nor a new
parser, which is a big plus.
Side note: repo-config, especially the updating side of
it, is one of the programs I find the most brittle in
the whole system, and it always makes me hesitate when
somebody proposes to use config file in any important
way read-write for this reason. But this "reading out
per-branch information from the file" is read-only so I
would not worry too much about it.
Strictly speaking, however, the config file is a wrong place to
store it. For one thing it has core.sharedrepository and
receive.denynonfastforwards that are true configuration to
control the behaviour of git _at_ _the_ _repository_ the
configuration is at. The new "branch property" are primarily to
help the other end, and the "filtering rewinding ones" we want
at the clone/fetch side wants that information only and not
interested in the true configuration information at that
repository.
So my preference is:
* store it in a fixed filename under $GIT_DIR/$something, in a
format that is similar to the true config file.
* Dumb transports would just do a file transfer, and we add a
new command (like "upload-pack", "upload-archive") for git
native transport to read that file. We might want to have a
protocol neutral wrapper (just like "ls-remote").
* Cloners and fetchers would do the file transfer and use
repo-config to read from that transferred file to find out
which are rewinding branches.
^ permalink raw reply
* feature request - cg up as synonym for cg update
From: Eric Blake @ 2006-11-26 5:19 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Coming from a CVS background, I am used to typing 'cvs up' instead of 'cvs
update', and was surprised when 'cg up' didn't work as an obvious
counterpart. According to 'cvs --help-synonyms', the complete list of
CVS's short synonyms:
$ cvs --help-synonyms
CVS command synonyms are:
add ad new
admin adm rcs
annotate ann
checkout co get
commit ci com
diff di dif
export exp ex
history hi his
import im imp
log lo
login logon lgn
rannotate rann ra
rdiff patch pa
release re rel
remove rm delete
rlog rl
rtag rt rfreeze
status st stat
tag ta freeze
update up upd
version ve ver
Many of these could probably be usefully implemented in cg, as one more
step for making life easy for converts from CVS to cogito.
- --
Life is short - so eat dessert first!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFaSPw84KuGfSFAYARAtOHAJ9DFlOC23HSWCq7qbVwU+KuT6uIMwCgsWgJ
byVaSGuoaA6JWx9hi6y85y8=
=n12u
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Junio C Hamano @ 2006-11-26 5:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <7virh2zxni.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> In either case, I do not think generating _both_ by default is a
> bad idea. They will become out of sync and the user either need
Eh, excuse me. "generating both is a BAD idea" is what I meant...
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Shawn Pearce @ 2006-11-26 7:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk61iyeq4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> > So now we're at a point of:
> >
> > * how do we get this branch information from the remote?
> > * how does the remote store this branch information?
>
> For the former, I was hoping that we could do a new action
> against remote repository that is "get remote information".
Yes, that is completely sane. :)
> As an implementation detail, I think it is one possibility to
> store this information in the config of the repository being
> cloned from. We should be able to use repo-config to
> parse that file in config-like syntax to extract what we would
> want, so we do not have to come up with a new syntax nor a new
> parser, which is a big plus.
Also quite sane. Nobody wants to write new code if we don't really
have to. :)
> Side note: repo-config, especially the updating side of
> it, is one of the programs I find the most brittle in
> the whole system, and it always makes me hesitate when
> somebody proposes to use config file in any important
> way read-write for this reason. But this "reading out
> per-branch information from the file" is read-only so I
> would not worry too much about it.
Now you tell me. git-gui uses repo-config for all of its option
data. It writes back to the config file to save user configured
options, including window layout at quit. It also uses both the
user global and the local repository config files. :)
We can safely update the index, symrefs and refs. Why can't we
also safely update the config file? The biggest problem is its
also a hand-modified file complete with support for comments,
so users expect the file to stay intact during edits. Aside from
that little issue its really a fairly simple format...
> Strictly speaking, however, the config file is a wrong place to
> store it. For one thing it has core.sharedrepository and
> receive.denynonfastforwards that are true configuration to
> control the behaviour of git _at_ _the_ _repository_ the
> configuration is at. The new "branch property" are primarily to
> help the other end, and the "filtering rewinding ones" we want
> at the clone/fetch side wants that information only and not
> interested in the true configuration information at that
> repository.
Yes, of course. I never suggested copy the entire configuration
as is. What we really want to do is take the branch data from the
remote and rewrite it for every branch we fetched into a ref, e.g.:
remote:
[branch "master"]
rewinds = false
description = blah blah
local:
[branch "remotes/origin/master"]
rewinds = false
description = blah blah
while skipping other configuration sections and options that have
no meaning for the local repository. core.sharedrepository is just
one of *many* configuration options that the local repository should
not inherit. remote.<name>.url is another... etc.
> So my preference is:
>
> * store it in a fixed filename under $GIT_DIR/$something, in a
> format that is similar to the true config file.
At which point you might as well put it into $GIT_DIR/config.
People are going to use git-repo-config to edit that file, even if
you say its brittle and maybe shouldn't be used for heavy editing.
Its just damn handy.
Besides of which, lets not forget that something like:
[branch "master"]
rewinds = false
[branch "pu"]
rewinds = true
is not only data for the client to examine. It can be useful in
say git-receive-pack as a much more fine-grained alternative to
receive.denynonfastforwards. If the server's policy is to not
rewind a branch then receive-pack shouldn't let a remote user
rewind it. At which point its useful to have that branch data
in $GIT_DIR/config. :-)
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Daniel Barkalow @ 2006-11-26 8:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yann Dirson, Steven Grimm, git
In-Reply-To: <Pine.LNX.4.64.0611251936590.3483@woody.osdl.org>
On Sat, 25 Nov 2006, Linus Torvalds wrote:
> On Sun, 26 Nov 2006, Yann Dirson wrote:
> >
> > Also, I'd rather expect "git-commit -a" outside of any submodule to
> > commit everything in the supermodule, triggering submodule commits as an
> > intermediate step when needed - just like "git-commit -a" does not
> > require to manually specify subdirectories to inclue in the commit. I'd
> > rather expect a special flag to exclude submodules from a commit.
>
> So, how do you do commit messages? It generally doesn't make sense to
> share the same commit message for submodules - the sub-commits generally
> do different things.
The same way you do the first commit message. Ask independantly for each
commit message in sequence with enough context in the comment section that
you know what you're talking about.
> I'd actually suggest that "git commit -a" with non-clean submodules error
> out for that reason, with something like
>
> submodule 'src/xyzzy' is not up-to-date, please commit changes to
> that first.
>
> exactly because you really generally should consider the submodule commits
> to be a separate phase.
I think this is getting close to the classic usability blunder of having
the program tell you what you should have done instead of what you did,
and then making you do it yourself, rather than just doing it.
Just have it run "git commit -a" in each dirty submodule recursively as
part of preparing the index, since that's what the user wants to do
anyway, and nothing already done would be affected.
"git commit -a -m <message>" should probably fail, of course.
-Daniel
^ permalink raw reply
* Re: [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Andy Parkins @ 2006-11-26 8:56 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <Pine.LNX.4.63.0611260141390.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On Sunday 2006, November 26 00:48, Johannes Schindelin wrote:
> This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_
> remoter.bla.fetch. To avoid that, you have to use "git repo-config
> remote.bla.fetch b ^$". (The last argument is a regular expression which
> has to be matched by the value-to-be-oreplaced.)
This is in git-clone; the config is empty. What is there to overwrite?
I'll fix it anyway.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Junio C Hamano @ 2006-11-26 9:13 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061126073942.GA30518@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
>> Strictly speaking, however, the config file is a wrong place to
>> store it. For one thing it has core.sharedrepository and
>> receive.denynonfastforwards that are true configuration to
>> control the behaviour of git _at_ _the_ _repository_ the
>> configuration is at. The new "branch property" are primarily to
>> help the other end, and the "filtering rewinding ones" we want
>> at the clone/fetch side wants that information only and not
>> interested in the true configuration information at that
>> repository.
>
> Yes, of course. I never suggested copy the entire configuration
> as is.
I never misunderstood your plan as such. I was more worried
about a case where you clone from a not-so-public repository and
the config file has some information of sensitive nature.
Currently we do not have any such variable, so I am probably
being a bit paranoid here, but using the config for the purpose
of what we are discussing right now closes the door to store
sensitive information and declare that the config file at the
remote is "none of the cloner's business".
However,...
> Besides of which, lets not forget that something like:
>
> [branch "master"]
> rewinds = false
> [branch "pu"]
> rewinds = true
>
> is not only data for the client to examine. It can be useful in
> say git-receive-pack as a much more fine-grained alternative to
> receive.denynonfastforwards. If the server's policy is to not
> rewind a branch then receive-pack shouldn't let a remote user
> rewind it. At which point its useful to have that branch data
> in $GIT_DIR/config. :-)
This is a good point. If we want to ever have a 'not to be
leaked' configuration per repository, we can have a separate,
private, configuration file to store that, so I probably should
not worry too much about this at this point. I'm Ok with having
this in the usual config -- the convenience outweighs the
purity.
To summarize:
* A repository can have branch."foo".rewinds configuration to
mark the "foo" branch to be subject to rewinding. This
configuration variable defaults to false.
* Receive.denynonfastforwards is currently a boolean but a new
value, "per-branch", is also allowed. When it is set to
"per-branch", non fast-forward update is allowed only when
branch."foo".rewinds is true for the branch.
* A cloner creates "Pull: refs/heads/*:refs/remotes/origin/*"
(or config equivalent) upon cloning. When it clones, it
downloads the config from the remote in order to see which
are marked as "rewinds". It makes tracking branches for only
the ones that are not marked as "rewinds" by default. We
might have an option to do '+' variant glob, and clone all
branches.
* Subsequent fetch, when the glob is not '+' variant, would
download the config from the remote in order to see which are
marked as "rewinds", and ignores the branches that are marked
as such.
I am a bit unhappy that subsequent fetches have to re-read the
remote config every time. I can sort-of-see we can cram the
"this is expected to be rewound" information as part of
peek-remote exchange to avoid the overhead, but I do not think
it is easily doable for dumb transports without breaking the
backward compatibility.
To avoid this, we need to remember what remote branches we have
seen but decided not to track, perhaps because they were marked
as "rewinds". Subsequent fetches first learn what are on the
remote side, and only when it sees a branch that we do not track
and we have not seen, it needs to re-read the remote config to
see if that is to be tracked (in which case we would create a
new tracking branch) or ignored (in which case we would remember
that we will ignore this branch in the future fetches).
^ permalink raw reply
* Re: [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Junio C Hamano @ 2006-11-26 9:15 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611260856.03057.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Sunday 2006, November 26 00:48, Johannes Schindelin wrote:
>
>> This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_
>> remoter.bla.fetch. To avoid that, you have to use "git repo-config
>> remote.bla.fetch b ^$". (The last argument is a regular expression which
>> has to be matched by the value-to-be-oreplaced.)
>
> This is in git-clone; the config is empty. What is there to overwrite?
The entry you wrote in the previous iteration in the same loop,
perhaps?
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Jakub Narebski @ 2006-11-26 9:32 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061126033433.GD29394@spearce.org>
Shawn Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Junio C Hamano wrote:
>>
>>> I am not sure if 'merge in corresponding branch' is the only
>>> valid workflow, however. I am reluctant to make the system
>>> automatically do so if the solution makes other workflows more
>>> painful to follow. Automatically merging remotes/origin/$foo
>>> when on $foo branch is not good enough, in other words (also,
>>> there may be a hierarchy under remotes/ other than origin). It
>>> might make sense to introduce "Merge: " in remotes/ file and if
>>> they are present use "Pull: " only to decide what are fetched
>>> and use "Merge: " to decide what is merged (if we were doing the
>>> system from scratch, the former would have been named "Fetch: "
>>> but it is too late now).
>>
>> If you add "Merge: " in remotes/, then please add it also in
>> remote section in config file. Config file has now
>> branch.<branchname>.merge (and it would be nice if clone would
>> set ou this for local branches corresponding to remote branches),
>> but it is not the same.
>
> I'm against adding anything to the remotes/ file format.
>
> We already have branch.<name>.merge to indicate what the default
> source for a git-pull on the branch named <name> should be.
> git-branch probably should fill that entry in when a branch is
> created from a remotes ref.
As I said, branch.<name>.merge is about something else: it just means
that if we are on <name> branch "git pull" will merge
branch.<name>.merge branch into it.
I think the "Merge: " or remote.<repo>.merge is about changing current
implicit rule: first branch is to be merged with current branch (if not
specified otherwise) when pull-ing, into explicit rule: branch marked
as "Merge: " is to be merged with current branch (unless specified
otherwise).
Correct me if I'm wrong, Junio.
--
Jakub Narebski
^ permalink raw reply
* [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Andy Parkins @ 2006-11-26 9:35 UTC (permalink / raw)
To: git
In-Reply-To: <7vvel2va9d.fsf@assigned-by-dhcp.cox.net>
Rather than use a separate config .git/remotes/ for remote shortcuts, this
patch adds the analogous definitions to .git/config using git-repo-config
calls.
For example what was previously .git/remotes/origin
URL: proto://host/path
Pull: refs/heads/master:refs/heads/origin
Is now added to .git/config as
[remote "origin"]
url = proto://host/path
fetch = refs/heads/master:refs/heads/origin
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Oops; you're absolutely right. I'd not realised that it was the add operation
that needed the special syntax rather than the replace.
git-clone.sh | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 9ed4135..19a5a63 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -373,9 +373,8 @@ then
*) origin_track="$remote_top/$origin"
git-update-ref "refs/heads/$origin" "$head_sha1" ;;
esac &&
- echo >"$GIT_DIR/remotes/$origin" \
- "URL: $repo
-Pull: refs/heads/$head_points_at:$origin_track" &&
+ git-repo-config remote."$origin".url "$repo" ^$ &&
+ git-repo-config remote."$origin".fetch "refs/heads/$head_points_at:$origin_track" ^$ &&
(cd "$GIT_DIR/$remote_top" && find . -type f -print) |
while read dotslref
do
@@ -389,8 +388,8 @@ Pull: refs/heads/$head_points_at:$origin_track" &&
then
continue
fi
- echo "Pull: refs/heads/${name}:$remote_top/${name}"
- done >>"$GIT_DIR/remotes/$origin" &&
+ git-repo-config remote."$origin".fetch "refs/heads/${name}:$remote_top/${name} ^$"
+ done &&
case "$use_separate_remote" in
t)
rm -f "refs/remotes/$origin/HEAD"
--
1.4.4.1.g9fd7
^ permalink raw reply related
* Re: [RFD] making separate-remote layout easier to use
From: Jakub Narebski @ 2006-11-26 9:43 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wnqwoxz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> * Subsequent fetch, when the glob is not '+' variant, would
> download the config from the remote in order to see which are
> marked as "rewinds", and ignores the branches that are marked
> as such.
>
> I am a bit unhappy that subsequent fetches have to re-read the
> remote config every time. I can sort-of-see we can cram the
> "this is expected to be rewound" information as part of
> peek-remote exchange to avoid the overhead, but I do not think
> it is easily doable for dumb transports without breaking the
> backward compatibility.
Perhaps below the "Pull: refs/heads/*:refs/remotes/origin/*" (or config
equivalent) we should list (in some format) branches which are not to be
fetched becaus they don't fast forward. One option, namely
Pull:-refs/heads/pu:refs/remotes/origin/pu
(or config equivalent)comes to mind. It has the advantage that when we
decide to fetch this branch, it would be as easy as changing '-' to '+'.
Or we can use '!' instead of '-' if you think it is more readable (probably
is).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Jakub Narebski @ 2006-11-26 9:49 UTC (permalink / raw)
To: git
In-Reply-To: <200611260935.43762.andyparkins@gmail.com>
Andy Parkins wrote:
> + git-repo-config remote."$origin".url "$repo" ^$ &&
Is this needed? As of now git supports I think only one URL entry per remote
anyway...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Marko Macek @ 2006-11-26 10:18 UTC (permalink / raw)
To: jonsmirl; +Cc: git
In-Reply-To: <9e4733910611201753m392b5defpb3eb295a075be789@mail.gmail.com>
Jon Smirl wrote:
>
> SVN hides the mini branch by creating a symbol like this:
>
> Symbol XXX, change set 70
> copy All from change set 50
> copy file A from change set 55
> copy file B,C from change set 60
> copy file D from change set 61
> copy file E,F,G from change set 63
> copy file H from change set 67
>
> It has to do all of those copies because the change sets weren't
> constructed while taking symbol dependency information into account.
>
> Symbol XXX can't copy from change set 69 because commits from after
> the symbol was created are included in change sets 51-69.
Sometimes it is not actually possible to have a 'simple' symbol, even
by following proper symbol dependencies.
Some situations:
- tags on some files are readjusted later, or tagged separately with an older
version
- tag is created with a -D "date" and the file times are not in sync
- tag is created from a mixed-revision working copy
While in the cases of 'time warp' the revision sequence should be
considered more important than timestamps, this is not necessarily
true for tags, since it's easily possible to create them on mixed
revisions.
cvs2svn also has a problem with vendor branches because it creates
tags/branches that contain files from vendor branch by copying some
files from the trunk and other files from the vendor branch.
If the vendor branch/tag was only used for the initial import,
it's IMO best to skip them in the conversion (this needs a patch).
There are however problems because keyword expansion causes file
differences.
It seems that mozilla CVS repository has vendor branches/imports in
some parts of the tree.
Mark
^ 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