* Re: [PATCH 3/4] Automatically detect a bare git repository.
From: Martin Waitz @ 2006-12-31 17:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, Theodore Tso
In-Reply-To: <20061231043019.GC5823@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
hoi :)
On Sat, Dec 30, 2006 at 11:30:19PM -0500, Shawn O. Pearce wrote:
> We test the current working directory only after we have tried
> searching up the directory tree. This is to retain backwards
> compatibility with our previous behavior on the off chance that
> a user has a 'refs' and 'objects' subdirectories and a 'HEAD'
> file that looks like a symref, all stored within a repository's
> associated working directory.
Hmm, I have my dot files under GIT control so I can't use this mechanism
to use bare GIT repositories under ~/git/*.git.
Perhaps we should test the current directory first, but check that it
ends in .git?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.
From: Junio C Hamano @ 2006-12-31 19:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Theodore Tso, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.63.0612311606330.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> While we're talking about potentially deprecating GIT_DIR for users,
>> out of curiosity, what valid workflows would cause users to want to
>> use GIT_INDEX_FILE and GIT_OBJECT_DIRECTORY? Seems like they would
>> cause more confusion and support problems than anything else.
>
> Easy, guys.
>
> It is a valid -- indeed, useful -- thing to be able to script nice
> helpers. For example, in one project I track tar balls. So, I wrote a
> script which will unpack the tar ball in a directory, build a new index
> from it, and commit the corresponding tree on top of the tracking branch.
> This setup relies _heavily_ on being able to redirect GIT_INDEX_FILE and
> GIT_DIR.
I do agree INDEX_FILE and OBJECT_DIRECTORY are handy things for
the user to muck around. What I am not sure about is GIT_DIR,
in the sense that I suspect it is not such a pain to do without
for such a script.
> ... Now, if somebody starts git in a
> bare repo, where "index" is present, it could die with a helpful message
> like
>
> It seems that this is a bare git repository, but there is an index
> file present, which contradicts that assumption. If the repository
> is indeed bare, please remove the index file.
That is probably worse.
* there is no reason for non working-tree operations such as
git-log to fail when you go to a bare repository (or for that
matter .git in a repository with a working-tree). we should
not have to error out nor remove the index we will not use.
* if you did the above in response to a misguided 'git
checkout' in a bare repository, the next error message the
user will get will be 'huh? you are in a bare repository,
bozo'.
So I do not think the helpful message should even be necessary.
^ permalink raw reply
* Re: [PATCH/RFH] send-pack: fix pipeline.
From: Linus Torvalds @ 2006-12-31 19:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wmgfm4s.fsf@assigned-by-dhcp.cox.net>
On Sun, 31 Dec 2006, Junio C Hamano wrote:
>
> Thanks. How about this?
Looks good to me. It should hopefully speed things up too, since now we
don't need to first walk the whole object list and then _re-walk_ it when
packing to get the size.
Linus
^ permalink raw reply
* Re: RFC: working with sparse work-copy: where to start?
From: Junio C Hamano @ 2006-12-31 19:56 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20061231104217.GE26552@mellanox.co.il>
"Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> Hi!
> I've been thinking about working in a sparsely-populated work copy.
> E.g. svn will let you do a checkout of a specific sub-directory
> and do all your development there assuming you only care about
> changes in that directory. Ideally, it would be possible to specify
> a set of directories that I care about.
> ...
> What other commands need to be fixed for this to work?
Pretty much everything needs to be changed, I suspect.
The point of git is to track the whole tree, and that is
ingrained to the design of the tool everywhere. You need to
bend backwards to operate in the way you propose; I am not
saying it is impossible but I suspect it will be very hard or
inefficient or both.
Your commits, although your working tree will only have selected
subtrees in "wrong" places, should have the same "directory
structure" as everybody else. This is an absolute requirement
for the result of your work in your repository to be usable by
others.
One design level thing you need to worry about is what to do
with merges, if you are pulling from more than one people and
they start their work in different version of "the whole tree".
You may not be interested in what happens in "other parts" of
the whole tree you are not checking out. For your merge result
to be any useful for other people you later want to merge from
you, you still have to come up with and record the sensible
result when these "other parts" have conflicts.
This means the tree objects you will create as the final product
has to have the same directory structure as other people, while
your working tree will have only selected things, and in "wrong"
(from the tree's perspective) places.
One decision you need to make early is which side you place your
index on.
One approach would be to have the same directory structure in
the index. The other possibility is to match the directory
structure recorded in the index with the structure of your
working tree. I am not sure pros-and-cons offhand.
Regardless of which avenue you pursue, you need to have a way to
tell your version of git which subtree your repository is
interested in, and where in your working tree you want to check
them out. And you would need to change affected commands to
take this new information into account when do their work.
The former approach means you do not have to touch write-tree
and read-tree, but your diff-index, diff-tree (when you want it
to work sensibly inside subdirectories), checkout-index and
update-index need to know about this. The latter means you do
not have to touch diff-files, update-index and checkout-index,
but read-tree will be affected. Any command that deals with
both tree and working directory at the same time (diff-index,
read-tree -u, merge-recursive, etc.) or works from a
subdirectory (pretty much all Porcelain commands -- think of
'git add .' in a subdirectory) will need to change regardless of
which approach is taken.
I think it would be a lot simpler if you do not mind deep
directory structure but still support a sparse checkout,
though.
^ permalink raw reply
* Re: Gitweb - caching
From: Jeff Garzik @ 2006-12-31 20:01 UTC (permalink / raw)
To: Robert Fitzsimons; +Cc: J.H., git
In-Reply-To: <20061231174123.GI6558@localhost>
Robert Fitzsimons wrote:
>> Thoughts or comments are welcome.
>
> Interesting work, John. Some initial comments:
>
> * It's a very intrusive set of changes.
> * An infinite expiry date isn't valid for all pages.
> * The other HTTP headers can change depending on the page returned.
> * A single cache directory is going to have problems as the number of
> cached files grows.
>
> What are the benefits of doing this inside of gitweb instead of using
> something like mod_cache or mod_perl handlers?
Or wrapping the gitweb output inside cgicache:
http://linux.yyz.us/projects.html
Jeff
^ permalink raw reply
* Re: Gitweb - caching
From: Jakub Narebski @ 2006-12-31 20:52 UTC (permalink / raw)
To: git
In-Reply-To: <20061231174123.GI6558@localhost>
Robert Fitzsimons wrote:
> * An infinite expiry date isn't valid for all pages.
An infinite expiry date is not valid at all. IIRC HTTP defines that
"infinite" expiry is one year.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Documentation: update glossary entry for "origin"
From: bfields @ 2006-12-31 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11676088582634-git-send-email-bfields@fieldses.org>
From: J. Bruce Fields <bfields@citi.umich.edu>
Update glossary entry for "origin" to reflect fact that it normally now refers
to a remote repository, not a branch.
Also, warning not to work on remote-tracking branches is no longer necessary
since git doesn't allow that.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/glossary.txt | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 894883d..7c1a659 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -188,11 +188,12 @@ octopus::
predator.
origin::
- The default upstream tracking branch. Most projects have at
+ The default upstream repository. Most projects have at
least one upstream project which they track. By default
'origin' is used for that purpose. New upstream updates
- will be fetched into this branch; you should never commit
- to it yourself.
+ will be fetched into remote tracking branches named
+ origin/name-of-upstream-branch, which you can see using
+ "git branch -r".
pack::
A set of objects which have been compressed into one file (to save
--
1.5.0.rc0.gac28
^ permalink raw reply related
* [PATCH] Documentation: update git-clone.txt for clone's new default behavior
From: bfields @ 2006-12-31 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11676088584199-git-send-email-bfields@fieldses.org>
From: J. Bruce Fields <bfields@citi.umich.edu>
Fix a couple remaining references to the origin branch.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git-clone.txt | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 874934a..9652320 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -75,16 +75,13 @@ OPTIONS
Also the branch heads at the remote are copied directly
to corresponding local branch heads, without mapping
them to `refs/remotes/origin/`. When this option is
- used, neither the `origin` branch nor the default
- `remotes/origin` file is created.
+ used, neither remote-tracking branches nor the related
+ configuration variables are created.
--origin <name>::
-o <name>::
- Instead of using the branch name 'origin' to keep track
- of the upstream repository, use <name> instead. Note
- that the shorthand name stored in `remotes/origin` is
- not affected, but the local branch name to pull the
- remote `master` branch into is.
+ Instead of using the remote name 'origin' to keep track
+ of the upstream repository, use <name> instead.
--upload-pack <upload-pack>::
-u <upload-pack>::
--
1.5.0.rc0.gac28
^ permalink raw reply related
* [PATCH] Documentation: remove master:origin example from pull-fetch-param.txt
From: bfields @ 2006-12-31 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11676088581948-git-send-email-bfields@fieldses.org>
From: J. Bruce Fields <bfields@citi.umich.edu>
This is no longer a useful example.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/pull-fetch-param.txt | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index e852f41..8d4e950 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -39,10 +39,6 @@ checkout -b my-B remote-B`). Run `git fetch` to keep track of
the progress of the remote side, and when you see something new
on the remote branch, merge it into your development branch with
`git pull . remote-B`, while you are on `my-B` branch.
-The common `Pull: master:origin` mapping of a remote `master`
-branch to a local `origin` branch, which is then merged to a
-local development branch, again typically named `master`, is made
-when you run `git clone` for you to follow this pattern.
+
[NOTE]
There is a difference between listing multiple <refspec>
--
1.5.0.rc0.gac28
^ permalink raw reply related
* [PATCH] Docs: update cvs-migration.txt to reflect clone's new default behavior
From: bfields @ 2006-12-31 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
From: J. Bruce Fields <bfields@citi.umich.edu>
I couldn't think of a really quick way to give all the details, so just refer
readers to the git-repo-config man page instead.
I haven't tested recent cvs import behavior--some time presumably it should be
updated to do something more similar to clone.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/cvs-migration.txt | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index b657f45..8e09bea 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -34,13 +34,10 @@ them first before running git pull.
[NOTE]
================================
-The first `git clone` places the following in the
-`my-project/.git/remotes/origin` file, and that's why the previous step
-and the next step both work.
-------------
-URL: foo.com:/pub/project.git/
-Pull: refs/heads/master:refs/remotes/origin/master
-------------
+The `pull` command knows where to get updates from because of certain
+configuration variables that were set by the first `git clone`
+command; see `git repo-config -l` and the gitlink:git-repo-config[1] man
+page for details.
================================
You can update the shared repository with your changes by first committing
--
1.5.0.rc0.gac28
^ permalink raw reply related
* [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: bfields @ 2006-12-31 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1167608858759-git-send-email-bfields@fieldses.org>
From: J. Bruce Fields <bfields@citi.umich.edu>
Update examples. I'm not sure if the last two examples are really useful
any more.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git-pull.txt | 75 +++++++++++++++++++++++++------------------
1 files changed, 44 insertions(+), 31 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 2a5aea7..5b9ff96 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -37,8 +37,15 @@ EXAMPLES
--------
git pull, git pull origin::
- Fetch the default head from the repository you cloned
- from and merge it into your current branch.
+ Update the remote tracking brances for the repository
+ you cloned from, then merge one of them into your
+ current branch. Normally the branch merged in is
+ the HEAD of the remote repository, when your master
+ branch is checked out. When on another branch,
+ the (alphabetically) first branch from the remote
+ repository is merged in. These defaults can be modified
+ using the branch and remote sections of the repository
+ configuration; see gitlink:git-repo-config[1] for details.
git pull -s ours . obsolete::
Merge local branch `obsolete` into the current branch,
@@ -58,51 +65,57 @@ You should refrain from abusing this option to sneak substantial
changes into a merge commit. Small fixups like bumping
release/version name would be acceptable.
-Command line pull of multiple branches from one repository::
+Pull of multiple branches from one repository using default configuration::
+
------------------------------------------------
-$ cat .git/remotes/origin
-URL: git://git.kernel.org/pub/scm/git/git.git
-Pull: master:origin
-
+$ git repo-config -l
+...
+remote.origin.url=git://git.kernel.org/pub/scm/git/git.git
+remote.origin.fetch=+refs/heads/*:refs/remotes/foo/*
+branch.master.remote=origin
+branch.master.merge=refs/heads/master
$ git checkout master
-$ git fetch origin master:origin +pu:pu maint:maint
-$ git pull . origin
+$ git fetch origin
+$ git pull . origin/master
------------------------------------------------
+
-Here, a typical `.git/remotes/origin` file from a
+Here, a typical configuration created by the
`git-clone` operation is used in combination with
-command line options to `git-fetch` to first update
-multiple branches of the local repository and then
-to merge the remote `origin` branch into the local
-`master` branch. The local `pu` branch is updated
-even if it does not result in a fast forward update.
+`git-fetch` to update all of the remote tracking
+branches for `origin` (the remote repository which
+you originally cloned from). Thanks to the "+" on
+the `remote.origin.fetch` line, the tracking branches
+will all be updated even if they do not result in a
+fast forward update.
++
+The `git pull` command then merges the newly
+fetched origin/master into the local `master` branch.
Here, the pull can obtain its objects from the local
repository using `.`, as the previous `git-fetch` is
known to have already obtained and made available
all the necessary objects.
++
+Note that given the configuration above, a simple
+`git pull` would have the same result as the above
+sequence of fetch and pull.
-Pull of multiple branches from one repository using `.git/remotes` file::
+Commandline pull of multiple branches from one repository::
+
------------------------------------------------
-$ cat .git/remotes/origin
-URL: git://git.kernel.org/pub/scm/git/git.git
-Pull: master:origin
-Pull: +pu:pu
-Pull: maint:maint
-
$ git checkout master
-$ git pull origin
+$ git fetch origin master:origin +pu:pu maint:maint
+$ git pull . origin
------------------------------------------------
+
-Here, a typical `.git/remotes/origin` file from a
-`git-clone` operation has been hand-modified to include
-the branch-mapping of additional remote and local
-heads directly. A single `git-pull` operation while
-in the `master` branch will fetch multiple heads and
-merge the remote `origin` head into the current,
-local `master` branch.
+Assuming the same configuration as above, this overrides
+the default fetch behavior, updating (or creating, as
+necessary) branches "origin", "pu", and "maint" in the
+local repository by fetching from the branches (respectively)
+"master", "pu", and "maint" from the remote repository.
++
+The "pu" branch will be updated even if it is does not
+fast-foward; the others will not be.
If you tried a pull which resulted in a complex conflicts and
@@ -112,7 +125,7 @@ gitlink:git-reset[1].
SEE ALSO
--------
-gitlink:git-fetch[1], gitlink:git-merge[1]
+gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-repo-config[1]
Author
--
1.5.0.rc0.gac28
^ permalink raw reply related
* [PATCH] Documentation: update tutorial's discussion of origin
From: bfields @ 2006-12-31 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1167608858532-git-send-email-bfields@fieldses.org>
From: J. Bruce Fields <bfields@citi.umich.edu>
Update tutorial's discussion of origin branch to reflect new defaults,
and include a brief mention of git-repo-config.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/tutorial.txt | 25 +++++++++++++++----------
1 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index cb808d9..d043e84 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -323,20 +323,25 @@ $ git pull
Note that he doesn't need to give the path to Alice's repository;
when Bob cloned Alice's repository, git stored the location of her
-repository in the file .git/remotes/origin, and that location is used
-as the default for pulls.
-
-Bob may also notice a branch in his repository that he didn't create:
+repository in the repository configuration, and that location is
+used for pulls:
-------------------------------------
-$ git branch
-* master
- origin
+$ git repo-config --get remote.origin.url
+/home/bob/myrepo
-------------------------------------
-The "origin" branch, which was created automatically by "git clone",
-is a pristine copy of Alice's master branch; Bob should never commit
-to it.
+(The complete configuration created by git-clone is visible using
+"git repo-config -l", and the gitlink:git-repo-config[1] man page
+explains the meaning of each option.)
+
+Git also keeps a pristine copy of Alice's master branch under the
+name "origin/master":
+
+-------------------------------------
+$ git branch -r
+ origin/master
+-------------------------------------
If Bob later decides to work from a different host, he can still
perform clones and pulls using the ssh protocol:
--
1.5.0.rc0.gac28
^ permalink raw reply related
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-01 0:35 UTC (permalink / raw)
To: bfields; +Cc: git
In-Reply-To: <11676088582634-git-send-email-bfields@fieldses.org>
bfields@fieldses.org writes:
> git pull, git pull origin::
> - Fetch the default head from the repository you cloned
> - from and merge it into your current branch.
> + Update the remote tracking brances for the repository
> + you cloned from, then merge one of them into your
> + current branch. Normally the branch merged in is
> + the HEAD of the remote repository, when your master
> + branch is checked out. When on another branch,
> + the (alphabetically) first branch from the remote
> + repository is merged in. These defaults can be modified
> + using the branch and remote sections of the repository
> + configuration; see gitlink:git-repo-config[1] for details.
I think documenting this is wrong. At least we should say "do
not be lazy and say 'git pull' or 'git pull origin' without
configuring what branch you are interested in when on a branch
you created yourself". Later, people can supply patches to make
that configuration easier.
When the user says "pull origin" while on another branch that
does not have branch.$that_branch.merge properly configured, it
happens to find the first remote branch -- which unfortunately
comes from the wildcard remote.origin.fetch created by clone to
say "track all remote branches".
What we wanted to do ideally was to forbid "git pull" that does
not have explicit refspec from the command line, without
configuring branch.*.merge. However this broke established
workflow of people who has remote.$origin.fetch configured to
list the remote branch to fetch explicitly; the merged branch
selection has always been "the first set of branches listed in
the configuration" and these peoples had their configuration
right without needing to have branch.*.merge at all.
Unfortunately git is too flexible around this area.
We probably could somehow arrante the remote branches that came
from wildcarding not subject to the merge branch selection
logic, but honestly I am tired of looking at that code for now.
An acceptable short-term workaround might be to revert the
effect of commit 3dd3d5b0.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: J. Bruce Fields @ 2007-01-01 1:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd55zd1nm.fsf@assigned-by-dhcp.cox.net>
On Sun, Dec 31, 2006 at 04:35:41PM -0800, Junio C Hamano wrote:
> bfields@fieldses.org writes:
>
> > git pull, git pull origin::
> > - Fetch the default head from the repository you cloned
> > - from and merge it into your current branch.
> > + Update the remote tracking brances for the repository
> > + you cloned from, then merge one of them into your
> > + current branch. Normally the branch merged in is
> > + the HEAD of the remote repository, when your master
> > + branch is checked out. When on another branch,
> > + the (alphabetically) first branch from the remote
> > + repository is merged in. These defaults can be modified
> > + using the branch and remote sections of the repository
> > + configuration; see gitlink:git-repo-config[1] for details.
>
> I think documenting this is wrong. At least we should say "do
> not be lazy and say 'git pull' or 'git pull origin' without
> configuring what branch you are interested in when on a branch
> you created yourself". Later, people can supply patches to make
> that configuration easier.
Yeah, OK, I'll admit I felt silly writing that; so for now, how about
just omitting mention of the current behavior and saying instead
something like this?:
".... Normally the branch merged in is
the HEAD of the remote repository, when your master
branch is checked out. For branches other than master,
you can choose the default remote branch to merge using the
branch.<name>.remote and branch.<name>.merge options; see
gitlink:git-repo-config[1] for details."
--b.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-01 1:44 UTC (permalink / raw)
To: bfields; +Cc: git, Shawn Pearce, Luben Tuikov, Johannes Schindelin
In-Reply-To: <7vd55zd1nm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> What we wanted to do ideally was to forbid "git pull" that does
> not have explicit refspec from the command line, without
> configuring branch.*.merge. However this broke established
> workflow of people who has remote.$origin.fetch configured to
> list the remote branch to fetch explicitly; the merged branch
> selection has always been "the first set of branches listed in
> the configuration" and these peoples had their configuration
> right without needing to have branch.*.merge at all.
>
> Unfortunately git is too flexible around this area.
>
> We probably could somehow arrante the remote branches that came
> from wildcarding not subject to the merge branch selection
> logic, but honestly I am tired of looking at that code for now.
I am still tired of looking at the code, but I would rather
look at it now than having to still look at it next year.
How about doing this? The difference this time around is that
if you have non-wildcard refspec listed first, which usually
is the case for people with established git workflow with
existing repositories, we use the old-and-proven rule to
merge the first set of refs. An earlier round botched this
completely by basing the logic on lack of branch.*.merge,
which broke for many people.
-- >8 --
[PATCH] Do not merge random set of refs out of wildcarded refs
When your fetch configuration has only the wildcards, we would
pick the lexicographically first ref from the remote side for
merging, which was complete nonsense. Make sure nothing except
the one that is specified with branch.*.merge is merged in this
case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 144f170..d2e4c2b 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -76,16 +76,32 @@ get_remote_default_refs_for_push () {
# from get_remote_refs_for_fetch when it deals with refspecs
# supplied on the command line. $ls_remote_result has the list
# of refs available at remote.
+#
+# The first token returned is either "explicit" or "glob"; this
+# is to help prevent randomly "globbed" ref from being chosen as
+# a merge candidate
expand_refs_wildcard () {
+ first_one=yes
for ref
do
lref=${ref#'+'}
# a non glob pattern is given back as-is.
expr "z$lref" : 'zrefs/.*/\*:refs/.*/\*$' >/dev/null || {
+ if test -n "$first_one"
+ then
+ echo "explicit"
+ first_one=
+ fi
echo "$ref"
continue
}
+ # glob
+ if test -n "$first_one"
+ then
+ echo "glob"
+ first_one=
+ fi
from=`expr "z$lref" : 'z\(refs/.*/\)\*:refs/.*/\*$'`
to=`expr "z$lref" : 'zrefs/.*/\*:\(refs/.*/\)\*$'`
local_force=
@@ -116,7 +132,8 @@ canon_refs_list_for_fetch () {
if test "$1" = "-d"
then
shift ; remote="$1" ; shift
- set x $(expand_refs_wildcard "$@")
+ set $(expand_refs_wildcard "$@")
+ is_explicit="$1"
shift
if test "$remote" = "$(get_default_remote)"
then
@@ -125,6 +142,10 @@ canon_refs_list_for_fetch () {
merge_branches=$(git-repo-config \
--get-all "branch.${curr_branch}.merge")
fi
+ if test -z "$merge_branches" && test $is_explicit != explicit
+ then
+ merge_branches=..this.will.never.match.any.ref..
+ fi
fi
for ref
do
^ permalink raw reply related
* Re: git-svn throwing assertion on old svn tracking branch
From: Eric Wong @ 2007-01-01 2:27 UTC (permalink / raw)
To: Nicolas Vilz; +Cc: git
In-Reply-To: <20061221010520.GB3901@localdomain>
Eric Wong <normalperson@yhbt.net> wrote:
> Nicolas Vilz <niv@iaglans.de> wrote:
> > hello guys,
> >
> > it has been a while, i tried git in conjunction with svn... i got a nice
> > history, when working with it. This Work is now a year old.
> >
> > Now I wanted to get on working and got following error message while
> > fetching from one specific svn tracking branch:
> >
> > $ git-svn fetch -i svn_master
> > perl: subversion/libsvn_subr/path.c:343: svn_path_remove_component:
> > Assertion `is_canonical(path->data, path->len)' failed.
> > Aborted
Actually, I just hit upon a weird bug in svm (SVN::Mirror) that was
similar to this (line 114 of the same file, 1.4.2dfsg1-2 in Debian).
Can you try taking the trailing slash out of the URL?
(.git/svn/svn_master/info/url).
Thanks.
--
Eric Wong
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Junio C Hamano @ 2007-01-01 3:21 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, Johannes Schindelin
In-Reply-To: <e5bfff550612310743t4ca1b017ubceddffafd06ac59@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 12/31/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>> Further, if you rely on parsing being super-fast, why not just parse
>> _only_ the header information that you actually need? The header still
>> consists of
>>
>> - exactly one "tree",
>> - an arbitrary amount of "parent" lines,
>> - exactly one "author", and
>> - exactly one "committer" line
>>
>> After that may come optional headers,
They are more like 'other' headers. Nobody said the set of
headers are cast in stone forever. The only things parsers
safely can assume are that the original four kinds come at the
beginning in the above order, and there is a blank line that
separates headers and the body.
> If you intorduce the concept of an 'optional header part' you
> logically and naturally _may_ also introduce the concept of disabling
> the display of _that_ optional header, or better, to keep back
> compatibility...
While I am somewhat sympathetic, and am willing to apologize for
trying to advance the i18n support without enough advance
warning, I think you already know what you are saying does not
make much sense in the larger picture and as the longer term
solution. Does any MUA ask the filesystem, POP3 server or IMAP
server not to give X-* headers?
We could declare "headers are cast in stone and we will not
enhance it in any way forever", and go back to my original hack
to use hidden trailer, but I do not think it would solve
anything. Porcelains that would try to take advantage of the
trailer would now start assuming incorrectly that the set of
trailers are cast in stone and will break when new information
is added to the trailer, which would bring us back to exactly
where we are now.
Having said that, I think what is in the current tip of 'master'
is of much less impact for normal repositories than the one that
bit you, in two aspects.
* Your sample commit had "encoding UTF-8" header, presumably
because the repository that the commit was created in had
core.commitencoding set to "UTF-8". The intent was not to
add anything when the log message is UTF-8, but the earlier
code was checking only for "utf-8". With the current tip of
master this should not happen anymore.
* When the output encoding conversion is done successfully, the
current tip of master drops "encoding" header from the
output, so in your sample situation where the commit has
(incorrectly) "encoding UTF-8" and your output encoding is
also "UTF-8" (because either you have core.commitencoding set
to it, or you do not have the configuration and let git fall
back to its default which is UTF-8), you would not see the
"encoding" header in the output from the rev-list.
The reason we did the latter, by the way, does not have anything
to do with helping broken parsers. We drop the header after
re-coding the log message into an encoding specified by the user
(which is presumably different from what the commit was
originally recorded in) because the encoding recorded on
"encoding" header would not match the re-coded log message
anymore.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-01 3:29 UTC (permalink / raw)
To: Junio C Hamano, bfields
Cc: git, Shawn Pearce, Luben Tuikov, Johannes Schindelin
In-Reply-To: <7vwt47bjwa.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > What we wanted to do ideally was to forbid "git pull" that does
> > not have explicit refspec from the command line, without
> > configuring branch.*.merge. However this broke established
> > workflow of people who has remote.$origin.fetch configured to
> > list the remote branch to fetch explicitly; the merged branch
> > selection has always been "the first set of branches listed in
> > the configuration" and these peoples had their configuration
> > right without needing to have branch.*.merge at all.
> >
> > Unfortunately git is too flexible around this area.
> >
> > We probably could somehow arrante the remote branches that came
> > from wildcarding not subject to the merge branch selection
> > logic, but honestly I am tired of looking at that code for now.
>
> I am still tired of looking at the code, but I would rather
> look at it now than having to still look at it next year.
>
> How about doing this? The difference this time around is that
> if you have non-wildcard refspec listed first, which usually
> is the case for people with established git workflow with
> existing repositories, we use the old-and-proven rule to
> merge the first set of refs. An earlier round botched this
> completely by basing the logic on lack of branch.*.merge,
> which broke for many people.
Can we please instead revisit the "branch.<name>.remote"
and "branch.<name>.merge" options?
What I'd really like to see and what really would be useful
to me every day is if I could individually _address_ a
"branch.<name>.remote" and "branch.<name>.merge" pair of
options.
I.e. I'd like to say "git-pull parent" or "git-pull parents"
in such and such branch, and this would pull the designated
parent(s) for the current branch. But if I'm in a different
branch (of the same repo) then the meaning of "parent" changes
accordingly.
Currently, the parent<-->child branch relationship only
exists in paper: for example: git master is the parent for
all my (local) branches, "git-upstream" is child of "next",
"git-lt-work" is child of "git-upstream" and "git-home" is
child of "git-lt-work", each one introducing its own
customizations and changes. I currently do the pull/merge
by hand, remembering the child/parent relationship and enforcing
it manually by the strict pull/merge sequence I do.
Of course we shouldn't break existing usages like
for example "git-pull . tag ...".
I can achieve the same thing using the "branch.*" options
today, but I do "git-pull" and I'm not entrirely satisfied
with that since in my head I know I'm doing a "parent->child"
merge and would like to express that on the command line.
So this is something of a cross between the remotes/ and
"branch.*" option.
For example "branch.<name>.<symbolic_ref>.fetch" and
"branch.<name>.<symbolic_ref>.merge" would do the trick.
Then at prompt, I say "git-pull <symbolic_ref>" which will
match local branch and symbolic name to whatever matches.
Of course, "branch..<symbolic_name>.*" would seem to be
identical to remotes. We should disallow that by stipulating
that a non-empty symbolic name imples non-empty branch name.
"branch.<name>..*" would be identical to its current usage.
The point is that the symbolic name changes its designation depending
on which is the current branch, and with a name like "parent" that
makes sense.
Luben
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: J. Bruce Fields @ 2007-01-01 3:48 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin
In-Reply-To: <59142.7095.qm@web31801.mail.mud.yahoo.com>
On Sun, Dec 31, 2006 at 07:29:22PM -0800, Luben Tuikov wrote:
> I.e. I'd like to say "git-pull parent" or "git-pull parents"
> in such and such branch, and this would pull the designated
> parent(s) for the current branch. But if I'm in a different
> branch (of the same repo) then the meaning of "parent" changes
> accordingly.
Could you explain a situation where this would be useful? A
"parent<-->child" relationship, where there's one upstream branch that
is always merged in, is easily handled; just replace your "git pull
parent" by a "git pull", right? Am I misunderstanding the proposal?
And is there any reason why your proposal conflicts with Junio's?
--b.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-01 5:13 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin
In-Reply-To: <20070101034825.GD15537@fieldses.org>
--- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Sun, Dec 31, 2006 at 07:29:22PM -0800, Luben Tuikov wrote:
> > I.e. I'd like to say "git-pull parent" or "git-pull parents"
> > in such and such branch, and this would pull the designated
> > parent(s) for the current branch. But if I'm in a different
> > branch (of the same repo) then the meaning of "parent" changes
> > accordingly.
>
> Could you explain a situation where this would be useful?
I don't know how to respond to this question.
> A
> "parent<-->child" relationship, where there's one upstream branch that
> is always merged in, is easily handled;
e is the base of natural logarithms.
> just replace your "git pull parent" by a "git pull", right?
Yes, but I don't want to just type "git-pull", I want to explicitly
type "git-pull parent" and depending in which branch I'm at, "parent"
would have identical meaning but would merge a different branch... because
I'm in a different branch...
(Since this is what is actually ment by the "branch.*" options.)
> Am I misunderstanding the proposal?
I did give an example of usage in my email to which you replied.
Basically I'd like to extend the concept of "branch spec" locally.
> And is there any reason why your proposal conflicts with Junio's?
Yes. Beating on a dead horse. "branch.*" options simply do not cut it.
We can either get rid of them completely or extend them to where they
are actually useful. Globbing resolution is secondary to resolving
the methodology.
HTH,
Luben
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: J. Bruce Fields @ 2007-01-01 5:45 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin
In-Reply-To: <951491.40207.qm@web31807.mail.mud.yahoo.com>
On Sun, Dec 31, 2006 at 09:13:49PM -0800, Luben Tuikov wrote:
> Yes, but I don't want to just type "git-pull", I want to explicitly
> type "git-pull parent" and depending in which branch I'm at, "parent"
> would have identical meaning but would merge a different branch... because
> I'm in a different branch...
Wouldn't it do what you want if by default "git branch new" and "git
checkout -b new" set branch.* options that pointed at the "parent"
branch?
The only reason I can see to require the extra bit of syntax ("git-pull
parent" instead of "git-pull") is if for the same branch you expect to
sometimes pull from one source and sometimes from another, and the pulls
from those various sources are common enough that it's worth defining
some shortcuts for more than one of them.
I can imagine sometimes doing that. (E.g. if you pull into your master
branch from upstream and from local topic branches.) But in that case
having to give the remote and branch name explicitly doesn't seem so
bad.
I dunno....
--b.
^ permalink raw reply
* [PATCH] git-svn: remove svnadmin dependency from the tests
From: Eric Wong @ 2007-01-01 5:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
We require the libraries now, so we can create repositories
using them (and save some executable load time while we're at
it).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/lib-git-svn.sh | 39 +++++++++++++++++----------------------
1 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index 99ada71..af42ccc 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -7,26 +7,10 @@ then
exit
fi
-perl -e 'use SVN::Core; $SVN::Core::VERSION gt "1.1.0" or die' >/dev/null 2>&1
-if test $? -ne 0
-then
- test_expect_success 'Perl SVN libraries not found, skipping test' :
- test_done
- exit
-fi
-
GIT_DIR=$PWD/.git
GIT_SVN_DIR=$GIT_DIR/svn/git-svn
SVN_TREE=$GIT_SVN_DIR/svn-tree
-svnadmin >/dev/null 2>&1
-if test $? -ne 1
-then
- test_expect_success 'skipping git-svn tests, svnadmin not found' :
- test_done
- exit
-fi
-
svn >/dev/null 2>&1
if test $? -ne 1
then
@@ -37,13 +21,24 @@ fi
svnrepo=$PWD/svnrepo
-set -e
-
-if svnadmin create --help | grep fs-type >/dev/null
+perl -w -e "
+use SVN::Core;
+use SVN::Repos;
+\$SVN::Core::VERSION gt '1.1.0' or exit(42);
+SVN::Repos::create('$svnrepo', undef, undef, undef,
+ { 'fs-config' => 'fsfs'});
+"
+x=$?
+if test $x -ne 0
then
- svnadmin create --fs-type fsfs "$svnrepo"
-else
- svnadmin create "$svnrepo"
+ if test $x -eq 42; then
+ err='Perl SVN libraries must be >= 1.1.0'
+ else
+ err='Perl SVN libraries not found or unusable, skipping test'
+ fi
+ test_expect_success "$err" :
+ test_done
+ exit
fi
svnrepo="file://$svnrepo"
--
1.5.0.rc0.g1ed48
^ permalink raw reply related
* [PATCH] git-svn: t/t9100-git-svn-basic: remove old check for NO_SYMLINK
From: Eric Wong @ 2007-01-01 5:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <1167630587505-git-send-email-normalperson@yhbt.net>
We don't support the svn command-line client anymore; nor
do we support anything before SVN 1.1.0, so we can be certain
symlinks will be supported in the SVN repository.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t9100-git-svn-basic.sh | 84 +++++++++++++++++++---------------------------
1 files changed, 35 insertions(+), 49 deletions(-)
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index c22fe47..040da92 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -24,10 +24,7 @@ test_expect_success \
mkdir import &&
cd import &&
echo foo > foo &&
- if test -z '$NO_SYMLINK'
- then
- ln -s foo foo.link
- fi
+ ln -s foo foo.link
mkdir -p dir/a/b/c/d/e &&
echo 'deep dir' > dir/a/b/c/d/e/file &&
mkdir bar &&
@@ -136,48 +133,43 @@ test_expect_success "$name" "
test -x '$SVN_TREE'/exec.sh"
-if test -z "$NO_SYMLINK"
-then
- name='executable file becomes a symlink to bar/zzz (file)'
-
- test_expect_success "$name" "
- rm exec.sh &&
- ln -s bar/zzz exec.sh &&
- git update-index exec.sh &&
- git commit -m '$name' &&
- git-svn set-tree --find-copies-harder --rmdir \
- remotes/git-svn..mybranch5 &&
- svn up '$SVN_TREE' &&
- test -L '$SVN_TREE'/exec.sh"
+name='executable file becomes a symlink to bar/zzz (file)'
+test_expect_success "$name" "
+ rm exec.sh &&
+ ln -s bar/zzz exec.sh &&
+ git update-index exec.sh &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch5 &&
+ svn up '$SVN_TREE' &&
+ test -L '$SVN_TREE'/exec.sh"
- name='new symlink is added to a file that was also just made executable'
+name='new symlink is added to a file that was also just made executable'
- test_expect_success "$name" "
- chmod +x bar/zzz &&
- ln -s bar/zzz exec-2.sh &&
- git update-index --add bar/zzz exec-2.sh &&
- git commit -m '$name' &&
- git-svn set-tree --find-copies-harder --rmdir \
- remotes/git-svn..mybranch5 &&
- svn up '$SVN_TREE' &&
- test -x '$SVN_TREE'/bar/zzz &&
- test -L '$SVN_TREE'/exec-2.sh"
-
- name='modify a symlink to become a file'
- test_expect_success "$name" "
- echo git help > help || true &&
- rm exec-2.sh &&
- cp help exec-2.sh &&
- git update-index exec-2.sh &&
- git commit -m '$name' &&
- git-svn set-tree --find-copies-harder --rmdir \
- remotes/git-svn..mybranch5 &&
- svn up '$SVN_TREE' &&
- test -f '$SVN_TREE'/exec-2.sh &&
- test ! -L '$SVN_TREE'/exec-2.sh &&
- diff -u help $SVN_TREE/exec-2.sh"
-fi
+test_expect_success "$name" "
+ chmod +x bar/zzz &&
+ ln -s bar/zzz exec-2.sh &&
+ git update-index --add bar/zzz exec-2.sh &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch5 &&
+ svn up '$SVN_TREE' &&
+ test -x '$SVN_TREE'/bar/zzz &&
+ test -L '$SVN_TREE'/exec-2.sh"
+name='modify a symlink to become a file'
+test_expect_success "$name" "
+ echo git help > help || true &&
+ rm exec-2.sh &&
+ cp help exec-2.sh &&
+ git update-index exec-2.sh &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch5 &&
+ svn up '$SVN_TREE' &&
+ test -f '$SVN_TREE'/exec-2.sh &&
+ test ! -L '$SVN_TREE'/exec-2.sh &&
+ diff -u help $SVN_TREE/exec-2.sh"
if test "$have_utf8" = t
then
@@ -203,12 +195,6 @@ test_expect_success "$name" \
git-rev-list --pretty=raw remotes/alt | grep ^tree | uniq > b &&
diff -u a b"
-if test -n "$NO_SYMLINK"
-then
- test_done
- exit 0
-fi
-
name='check imported tree checksums expected tree checksums'
rm -f expected
if test "$have_utf8" = t
--
1.5.0.rc0.g1ed48
^ permalink raw reply related
* [PATCH] git-svn: t/t91??-*: optimize the tests a bit
From: Eric Wong @ 2007-01-01 5:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <1167630588899-git-send-email-normalperson@yhbt.net>
This removes some unnecessary 'svn up' calls throughout
t9103-git-svn-graft-branches.sh:
* removed an 'svn log' call that was leftover from debugging
* removed multiple git-svn calls with a multi-init / multi-fetch
combination (which weren't tested before, either)
* replaced `rev-list ... | head -n1` with `rev-parse ...`
(not sure what I was thinking when I wrote that)
All this saves about 9 seconds from a test run
(53s -> 44s for 'make t91*') on my 1.3GHz Athlon
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t9101-git-svn-props.sh | 11 +++--------
t/t9103-git-svn-graft-branches.sh | 14 ++++----------
t/t9104-git-svn-follow-parent.sh | 1 -
3 files changed, 7 insertions(+), 19 deletions(-)
diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
index 5543b07..46fcec5 100755
--- a/t/t9101-git-svn-props.sh
+++ b/t/t9101-git-svn-props.sh
@@ -57,13 +57,10 @@ test_expect_success 'setup some commits to svn' \
'cd test_wc &&
echo Greetings >> kw.c &&
svn commit -m "Not yet an Id" &&
- svn up &&
echo Hello world >> kw.c &&
svn commit -m "Modified file, but still not yet an Id" &&
- svn up &&
svn propset svn:keywords Id kw.c &&
- svn commit -m "Propset Id" &&
- svn up &&
+ svn commit -m "Propset Id"
cd ..'
test_expect_success 'initialize git-svn' "git-svn init $svnrepo"
@@ -86,8 +83,7 @@ test_expect_success "propset CR on crlf files" \
svn propset svn:eol-style CR empty &&
svn propset svn:eol-style CR crlf &&
svn propset svn:eol-style CR ne_crlf &&
- svn commit -m "propset CR on crlf files" &&
- svn up &&
+ svn commit -m "propset CR on crlf files"
cd ..'
test_expect_success 'fetch and pull latest from svn and checkout a new wc' \
@@ -111,8 +107,7 @@ cd test_wc
svn propset svn:eol-style CRLF ne_cr &&
svn propset svn:keywords Id cr &&
svn propset svn:keywords Id ne_cr &&
- svn commit -m "propset CRLF on cr files" &&
- svn up'
+ svn commit -m "propset CRLF on cr files"'
cd ..
test_expect_success 'fetch and pull latest from svn' \
'git-svn fetch && git pull . remotes/git-svn'
diff --git a/t/t9103-git-svn-graft-branches.sh b/t/t9103-git-svn-graft-branches.sh
index 293b98f..b5f7677 100755
--- a/t/t9103-git-svn-graft-branches.sh
+++ b/t/t9103-git-svn-graft-branches.sh
@@ -16,25 +16,19 @@ test_expect_success 'initialize repo' "
cd wc &&
echo feedme >> branches/a/readme &&
svn commit -m hungry &&
- svn up &&
cd trunk &&
svn merge -r3:4 $svnrepo/branches/a &&
svn commit -m 'merge with a' &&
cd ../.. &&
- svn log -v $svnrepo &&
- git-svn init -i trunk $svnrepo/trunk &&
- git-svn init -i a $svnrepo/branches/a &&
- git-svn init -i tags/a $svnrepo/tags/a &&
- git-svn fetch -i tags/a &&
- git-svn fetch -i a &&
- git-svn fetch -i trunk
+ git-svn multi-init $svnrepo -T trunk -b branches -t tags &&
+ git-svn multi-fetch
"
r1=`git-rev-list remotes/trunk | tail -n1`
r2=`git-rev-list remotes/tags/a | tail -n1`
r3=`git-rev-list remotes/a | tail -n1`
-r4=`git-rev-list remotes/a | head -n1`
-r5=`git-rev-list remotes/trunk | head -n1`
+r4=`git-rev-parse remotes/a`
+r5=`git-rev-parse remotes/trunk`
test_expect_success 'test graft-branches regexes and copies' "
test -n "$r1" &&
diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index 8d2e2fe..400c21c 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh
@@ -17,7 +17,6 @@ test_expect_success 'initialize repo' "
cd wc &&
echo world >> trunk/readme &&
svn commit -m 'another commit' &&
- svn up &&
svn mv -m 'rename to thunk' trunk thunk &&
svn up &&
echo goodbye >> thunk/readme &&
--
1.5.0.rc0.g1ed48
^ permalink raw reply related
* [RFC/PATCH] fail pull/merge early in the middle of conflicted merge
From: Junio C Hamano @ 2007-01-01 7:21 UTC (permalink / raw)
To: git
After a pull that results in a conflicted merge, a new user
often tries another "git pull" in desperation. When the index
is unmerged, merge backends correctly bail out without touching
either index nor the working tree, so this does not make the
wound any worse.
The user will however see several lines of messsages during this
process, such as "filename: needs merge", "you need to resolve
your current index first", "Merging...", and "Entry ... would be
overwritten by merge. Cannot merge.". They are unnecessarily
alarming, and makes useful conflict messages from the first pull
scroll off the top of the terminal.
This changes pull and merge to run "git-ls-files -u" upfront and
stop them much earlier than we currently do.
Old timers may know better and would not to try pulling again
before cleaning things up; this change adds extra overhead that
is unnecessary for them. But this would be worth paying for to
save new people from needless confusion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I've seen some people on #git channel got totally confused
after a conflicted merge at least three times, and they paste
the diagnostics from the second and subsequent pull, assuming
that the messages would help diagnosing the situation in any
way (unfortunately they typically don't). But it is not the
user's fault not to know it. With this what they can give us
when asking for help will only be from the first pull. In a
sense, the real motivation of this patch is to make life
easier for people who want to help these new people.
git-merge.sh | 3 +++
git-pull.sh | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index ba42260..f43fa69 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -8,6 +8,9 @@ USAGE='[-n] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commi
. git-sh-setup
set_reflog_action "merge $*"
+test -z "$(git ls-files -u)" ||
+ die "You are in a middle of conflicted merge."
+
LF='
'
diff --git a/git-pull.sh b/git-pull.sh
index 28d0819..49130d5 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -9,6 +9,9 @@ LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEA
. git-sh-setup
set_reflog_action "pull $*"
+test -z "$(git ls-files -u)" ||
+ die "You are in a middle of conflicted merge."
+
strategy_args= no_summary= no_commit= squash=
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
do
^ permalink raw reply related
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