* [PATCH] Wrap completions in `type git' conditional statement.
From: Sung Pae @ 2009-11-12 9:56 UTC (permalink / raw)
To: spearce; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
Hello,
I don't know if this has come up before (I didn't notice in a casual grep of git log), but attached is a little patch to wrap the bash completion script in a `type git' check.
From the patch header:
--
The onus for checking if a command exists before loading its completions
properly falls on individual completion files since they are normally
sourced from a completions directory (e.g. source /etc/bash_completion.d/*),
or perhaps from a single file concatenated from other completion files.
Also, this is standard practice with other bash-completion scripts.
--
Cheers,
Sung Pae
[-- Attachment #2: 0001-completion-Wrap-completions-in-type-git-conditional-.patch --]
[-- Type: application/octet-stream, Size: 2323 bytes --]
From 5e9d29fa1938554903631a4b560e08211b8efab3 Mon Sep 17 00:00:00 2001
From: Sung Pae <sung@metablu.com>
Date: Thu, 12 Nov 2009 02:55:28 -0600
Subject: [PATCH] completion: Wrap completions in `type git' conditional statement
The onus for checking if a command exists before loading its completions
properly falls on the individual completion files since they are normally
sourced from a completions directory (e.g. source /etc/bash_completion.d/*), or
perhaps from a single file concatenated from other completion files.
Also, this is standard practice with other bash-completion scripts.
---
contrib/completion/git-completion.bash | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e3ddecc..f1f9fb8 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -18,16 +18,13 @@
# To use these routines:
#
# 1) Copy this file to somewhere (e.g. ~/.git-completion.sh).
-# 2) Added the following line to your .bashrc:
+# 2) Add the following line to your .bashrc:
# source ~/.git-completion.sh
#
-# 3) You may want to make sure the git executable is available
-# in your PATH before this script is sourced, as some caching
-# is performed while the script loads. If git isn't found
-# at source time then all lookups will be done on demand,
-# which may be slightly slower.
+# Note that git must be available in your PATH or as an alias at the
+# time of sourcing.
#
-# 4) Consider changing your PS1 to also show the current branch:
+# 3) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
#
# The argument to __git_ps1 will be displayed only if you
@@ -60,6 +57,8 @@
# git@vger.kernel.org
#
+{ type git || type git.exe; } &>/dev/null && {
+
case "$COMP_WORDBREAKS" in
*:*) : great ;;
*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
@@ -2242,3 +2241,5 @@ if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
complete -o bashdefault -o default -o nospace -F _git git.exe 2>/dev/null \
|| complete -o default -o nospace -F _git git.exe
fi
+
+} # type git
--
1.6.5
^ permalink raw reply related
* Re: git-svn problem with v1.6.5
From: Pascal Obry @ 2009-11-12 10:00 UTC (permalink / raw)
To: Eric Wong; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <20091112093509.GA617@dcvr.yhbt.net>
Eric,
> Yes, you need to recreate all the .rev_map* files if you use
> filter-branch. Just remove them and they should be automatically
> recreated for your case (not using --no-metadata or --use-svm-props)
Thanks for the confirmation, I'll do that.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: Locally manage user/branch setting files without pushing them remotely
From: Daniele Segato @ 2009-11-12 10:13 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Git Mailing List
In-Reply-To: <20091112093146.GB25398@vidovic>
On Thu, Nov 12, 2009 at 10:31 AM, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:
> I don't understand. You'll still have to manually these files regardless
> _how_ they are tracked.
the first time i clone the repo I had to compile them manually...
but then I would like to keep different setting in my different branches and
I would like to find a way to "load" the right conf file automatically
when I switch repo
> When I say, "out of the main development repository", I don't think "out
> of the directory of the repository" but "out of the tracking git system".
of course, which is almost the same
> I think you should look at 'git subtree' or 'git submodule' to track the
> setting files out of the _main_ repository and _inside_ the main
> development directory.
will they work with git-svn?
I'm not very familiar with them anyway.
>> we are customizing a third party product and I can't change the way it
>> is build up.
>>
>> I don't think that this situation is so uncommon anyway.
>
> Yeah, it doesn't help to be unable to do everything we want! But I'm
> pretty sure git can do something very convenient in your case.
you are right..
but since this is not so uncommon I think other people has found a way
to handle it.
May be using an external/local repository for those files.
but then I would like to have a way to link them automatically.
may be this can be achieved with some hook script..
What I have in mind is something like this:
1. creating a local repo "confrepo" on the same directory where I have
the real repo
2. .gitignore for all my local config file in the real repo
3. using the confrepo to store my local scripts and replicate in it
the same branch structure of my real repo
4. may be then I can create some hook script that when I do
$ git checkout experimental
a) it try to do the same on the confrepo (checkout experimental), if
the branch doesn't exist it does nothing else
b) copy everythink in the confrepo to my realrepo (overwriting if needed)
that way I could have something automatic. The only think I couldn't
have is, looking back in history, a way to know which config was in
place for an old commit.
could you tell me if this is even possible?
I'm going a little off-topic here proposing an idea for a new feature
What about adding a git feature to "link" different git repository?
Or providing a way to have 2 (or more) git repository in the same working area.
an ipotetical usage:
$ mkdir realrepo && cd realrepo
$ git (svn) clone http://whatever... .
--> master
$ git link createrepo ../confrepo confs
--> Initialized repo ../confrepo
--> Linked repo confs to ../confrepo
--> Created branch master in ../confrepo
$ touch localconf.properties
$ touch real-repo-file.c
$ git add real-repo.file.c
--> added real-repo-file.c to stage (as usual)
$ git link add localconf.properties
--> Added local.conf.properties to confs stage
$ git commit
--> standard commit
--> added localconf.properties to .gitignore (or .git/info/exclude)
--> commit on confs
$ git checkout -b experimental # creating new branch
--> checkout -b experimental on confs
$ # modify many things and the localconf.properties
$ git status
--> show standard output and on new section "linked files":
localconf.properties on confs has been modified
$ git add . && git commit
--> localconf.properties is committed in "confs" repository branch
"experimental"
$ git checkout master
--> checkout master on confs
--> copy all files of the confs repo to the current real repo working area
I think you got the idea.
the "linked" repo could also keep a tracked files like this:
.gitlink-source
which could keep the commit SHA of the real repo for each commit in
the confs repo
so that you had a way to get the right "confs" commit associated with
each commit on the real repo.
I don't know git enough to see how this could be hard or which
drawback could have.
^ permalink raw reply
* [TopGit PATCH] --strip option for tg export
From: Heiko Hund @ 2009-11-12 10:15 UTC (permalink / raw)
To: git; +Cc: Heiko Hund
This introduces the '--strip[=N]' option for 'tg export --quilt' to enable
export of a flat quilt series, even if the tg branch names are structured
hierarchically.
It may be useful if you - like me - structure your topgit branches like
"t/<NN>/<NAME>" to keep the overview in git, but don't want the exported
quilt series to be spread across subdirectories.
In contrast to '--flatten' this option removes the first 'N' or all
subdirectories from the topgit branch name, while keeping compatible with
the existing options. The remaining ones can still be flattened. Patch
names can still get numbered.
Signed-off-by: Heiko Hund <hhund@astaro.com>
---
README | 8 +++++---
tg-export.sh | 47 +++++++++++++++++++++++++++++++++++++----------
2 files changed, 42 insertions(+), 13 deletions(-)
diff --git a/README b/README
index 495c70b..44b60e1 100644
--- a/README
+++ b/README
@@ -429,9 +429,11 @@ tg export
In '--quilt' mode the patches are named like the originating topgit
branch. So usually they end up in subdirectories of the output
directory. With option '--flatten' the names are mangled such that
- they end up directly in the output dir (i.e. slashed are substituted by
- underscores). With '--numbered' (which implies '--flatten') the patch
- names get a number as prefix to allow getting the order without
+ they end up directly in the output dir (i.e. slashes are substituted by
+ underscores). With option '--strip[=N]' the first 'N' subdirectories (all
+ if no 'N' is given) get stripped off. Names are always '--strip'ped
+ before '--flatten'ed. With option '--numbered' (which implies '--flatten')
+ the patch names get a number as prefix to allow getting the order without
consulting the series file, which eases sending out the patches.
Usage: tg export ([(--collapse | --linearize)] BRANCH | --quilt DIR)
diff --git a/tg-export.sh b/tg-export.sh
index a16c290..a65c731 100644
--- a/tg-export.sh
+++ b/tg-export.sh
@@ -9,6 +9,8 @@ output=
driver=collapse
flatten=false
numbered=false
+strip=false
+stripval=0
## Parse options
@@ -23,6 +25,17 @@ while [ -n "$1" ]; do
--numbered)
flatten=true;
numbered=true;;
+ --strip*)
+ val=${arg#*=}
+ if [ "$val" = "--strip" ]; then
+ strip=true
+ stripval=9999
+ elif [ -n "$val" -a "x$(echo $val | sed -e 's/[0-9]//g')" = "x" ]; then
+ strip=true
+ stripval=$val
+ else
+ die "invalid parameter $arg"
+ fi;;
--quilt)
driver=quilt;;
--collapse)
@@ -49,6 +62,9 @@ done
[ "$driver" = "quilt" ] || ! "$flatten" ||
die "--flatten works only with the quilt driver"
+[ "$driver" = "quilt" ] || ! "$strip" ||
+ die "--strip works only with the quilt driver"
+
if [ -z "$branches" ]; then
# this check is only needed when no branches have been passed
name="$(git symbolic-ref HEAD | sed 's#^refs/heads/##')"
@@ -162,16 +178,27 @@ quilt()
return
fi
- if "$flatten"; then
- bn="$(echo "$_dep.diff" | sed -e 's#_#__#g' -e 's#/#_#g')";
- dn="";
- else
- bn="$(basename "$_dep.diff")";
- dn="$(dirname "$_dep.diff")/";
- if [ "x$dn" = "x./" ]; then
- dn="";
- fi;
- fi;
+ _dep_tmp=$_dep
+
+ if "$strip"; then
+ i=$stripval
+ while [ "$i" -gt 0 ]; do
+ [ "$_dep_tmp" = "${_dep_tmp#*/}" ] && break
+ _dep_tmp=${_dep_tmp#*/}
+ i=$((i - 1))
+ done
+ fi
+
+ bn="$(basename "$_dep_tmp.diff")"
+ dn="$(dirname "$_dep_tmp.diff")/"
+ [ "x$dn" = "x./" ] && dn=""
+
+ if "$flatten" && [ "$dn" ]; then
+ bn="$(echo "$_dep_tmp.diff" | sed -e 's#_#__#g' -e 's#/#_#g')"
+ dn=""
+ fi
+
+ unset _dep_tmp
if [ -e "$playground/$_dep" ]; then
# We've already seen this dep
--
tg: (f59e4f9..) strip_param_for_export (depends on: 0.8)
^ permalink raw reply related
* git svn show-ignore bug?
From: Niko Schwarz @ 2009-11-12 11:13 UTC (permalink / raw)
To: git; +Cc: normalperson
Hi there, in the IRC channel today, someone asked me to report this
behavior to you because they suspect a bug in show-ignore.
Ok, so here's the output of git svn info:
Path: .
URL: https://www.iam.unibe.ch/scg/svn_repos
Repository Root: https://www.iam.unibe.ch/scg/svn_repos
Repository UUID: 54883e8d-cf1d-0410-83d6-f114b9419f37
Revision: 29639
Node Kind: directory
Schedule: normal
Last Changed Author: oscar
Last Changed Rev: 29639
Last Changed Date: 2009-11-12 11:22:35 +0100 (Do, 12 Nov 2009)
I can do git svn rebase, git svn fetch, and those things work.
Dcommit, works, too. But git svn show-ignore >> .gitignore does not
work.
This is the dialog with the system:
Nikos-Mbp-3:svn_repos niko$ git svn show-ignore >> .gitignore
Authentication realm: <https://www.iam.unibe.ch:443> SCG Subversion
Repository
Password for 'schwarz':
Authentication realm: <https://www.iam.unibe.ch:443> SCG Subversion
Repository
Username: schwarz
Password for 'schwarz':
Authentication realm: <https://www.iam.unibe.ch:443> SCG Subversion
Repository
Username: schwarz
Password for 'schwarz':
Autorisierung schlug fehl: PROPFIND von »/scg/svn_repos/IAM«:
Autorisierung schlug fehl: Could not authenticate to server: rejected
Basic challenge (https://www.iam.unibe.ch) at /opt/local/libexec/git-
core/git-svn line 2276
That's all the info I have, I'm afraid. I'm sure that the password is
correct, as it works from XCode.
Thanks in advance, cheers,
Niko
^ permalink raw reply
* Re: Locally manage user/branch setting files without pushing them remotely
From: Nicolas Sebrecht @ 2009-11-12 11:15 UTC (permalink / raw)
To: Daniele Segato; +Cc: Nicolas Sebrecht, Git Mailing List
In-Reply-To: <9accb4400911120213w35efcad3q8a24d99c37a5e8c5@mail.gmail.com>
The 12/11/09, Daniele Segato wrote:
>
> > I think you should look at 'git subtree' or 'git submodule' to track the
> > setting files out of the _main_ repository and _inside_ the main
> > development directory.
>
> will they work with git-svn?
> I'm not very familiar with them anyway.
Not the way you'd like to, I think. This could mean having as many svn
repo as git subtree/submodule.
> May be using an external/local repository for those files.
> but then I would like to have a way to link them automatically.
>
> may be this can be achieved with some hook script..
You could look at 'man githooks'.
> What I have in mind is something like this:
>
> 1. creating a local repo "confrepo" on the same directory where I have
> the real repo
> 2. .gitignore for all my local config file in the real repo
> 3. using the confrepo to store my local scripts and replicate in it
> the same branch structure of my real repo
>
> 4. may be then I can create some hook script that when I do
>
> $ git checkout experimental
>
> a) it try to do the same on the confrepo (checkout experimental), if
> the branch doesn't exist it does nothing else
> b) copy everythink in the confrepo to my realrepo (overwriting if needed)
>
>
> that way I could have something automatic. The only think I couldn't
> have is, looking back in history, a way to know which config was in
> place for an old commit.
>
>
> could you tell me if this is even possible?
I think, yes.
> I'm going a little off-topic here proposing an idea for a new feature
> What about adding a git feature to "link" different git repository?
> Or providing a way to have 2 (or more) git repository in the same working area.
Patches are welcome. That said, I guess it won't be needed. As you
pointed out, the flexibility has been implemented in the hooks system.
Consequently, we all have to write the appropriate scripts. But OTOH, it
is more flexible than any feature matching _one_ workflow.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Michael J Gruber @ 2009-11-12 11:29 UTC (permalink / raw)
To: Felipe Contreras
Cc: Jonathan Nieder, Junio C Hamano, git, J. Bruce Fields,
Hannu Koivisto, Jeff King, Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <94a0d4530911111515q643e263bn3adc6b47cd968d3d@mail.gmail.com>
Felipe Contreras venit, vidit, dixit 12.11.2009 00:15:
> On Sun, Oct 25, 2009 at 1:14 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Felipe Contreras wrote:
>>> Supposing that color.ui is 'auto' by default,
>>
>> Should it be? I think it would not be too hard to detect a color
>> terminal by checking $TERM. Are many people bothered by color? Do we
>> need some way to make it more obvious how to turn color _off_?
>
> I think it should be.
Back then (before my involvement with git) the result of the discussion
was something like: "Since some of us are way more opposed to the use of
colors than others are in favor..." This does not sound overly democratic.
Feel free to bring this issue on for a change in Git 1.7.0. It would be
good to research any possible incompatibilities this would imply (other
than the looks of the output),
>>> No, but "improving" needs "changing", and the discussion I see is
>>> biased towards "not changing".
>> [...]
>>> I don't think the user manual is achieving that purpose. I don't know
>>> if it's the user manual's fault, or git's UI. Both areas need a lot of
>>> improvement (as the git user survey suggests), and I've tried to
>>> improve both with a lot resistance in both. So I'm not very hopeful
>>> anymore.
>>
>> I hope you have not misunderstood. I cannot speak for everyone else
>> here, but I know I am happier when (1) fixes match problems to be
>> solved in a documented way and (2) fixes do not unnecessarily break
>> unrelated habits. One way to bring this about is to justify each
>> change by explaining what real problem it will solve and how it avoids
>> collateral damage. Without that justification, a change is indeed
>> dangerous and might be worth resisting until it gets clarified. But
>> this is not meant to prevent fixes from occuring at all.
>
> Well. I've sent many patches, and gone through several iterations.
> After fixing all outstanding issues, addressing all the comments, and
> getting several "I like this" votes, Junio suddenly decides he doesn't
> like the initial changes at all and doesn't provide any way forward.
>
> I don't see how that's an environment that fosters changes.
The process can be frustrating at times. Many patches go through many
rounds. I've had occasions where I got frustrated and gave up, as well
as those where I learned a lot and the actual result was much better
than it would have been without thorough discussions. It's this process
which tries to ensure that the project is moving forward most of the
time, rather than sporadically back and forth; moving forward maybe a
bit slower, but still at an impressive overall rate.
Regarding this specific patch series: I took part in the initial
discussion, and got frustrated by the original poster's seemingly
unwillingness to accept advice, so I left. I'm not drawing any general
conclusions, and please don't take this as an ad hominem argument.
Sometimes it's simply a matter of mismatching participants.
It's just my impression that many people retreat from a discussion
because they feel it's getting unproductive (from their particular point
of view), maybe hoping the thread will die out sooner or later. Once it
looks as if something they object to could be included they come back
with counter arguments. This makes the discussion seemingly go back and
forth, but is a natural sociological effect.
>> Could you list some UI patches that were overlooked or not properly
>> addressed? Maybe people just forgot about them or were waiting for an
>> updated version, or maybe the problems some solve weren’t articulated
>> clearly yet. I would be glad to help out in any way I can.
>
> For example there have been many attempts to bring the 'git stage' to
> foreground of the UI; right now it's kind of hidden and many people
> don't even realize it's there. Even simplistic attempts as
> standardizing --index, --cache and so on into --stage have failed
> miserably.
>
> Again, there doesn't seem to be a path forward. Perhaps the git's
> stage will remain an obscure feature of git forever. (all the input
> from git user's survey points out that people are not really using it)
I didn't read that out of the survey. On the other hand, the last survey
pretty impressively showed where it had been publicized most
prominently. One should keep that in mind when interpreting the results.
If you care to go back to that discussion you see that there is good
reason for having both --cached and --index. They are different. "git
help cli" explains this nicely.
"To stage" has been introduced to describe what "git add" does to people
who hard wire "add" to the meaning it has in other VCSes. In fact, this
would be unnecessary if the concept of Git as a *content* tracker could
be transmitted more successfully. Git cares about content only, so what
could "git add" possibly mean?
"git stage" is a failed follow up ui experiment.
In this regard, I think the problem is that there are really two kinds
of people in terms of learning style:
- Some prefer recipes, similarities with previously known recipes. "How
do I...?" And then try do understand "How does (G)it...?" from that.
- Some want to understand concepts first: "How does (G)it...?" And then
figure out how to use (G)it to do what they want.
I'd guess most developers and a large fraction of the "technical crowd"
belong in the second camp.
I still think we should both
- try and teach concepts early, emphasize that Git is different
(content, index, branch - that's it)
- make Git behave in "expected ways", making it easy for the (willing)
beginner) without compromising its usefulness as a power tool.
I better stop before I digress even more from the original topic :)
Michael
^ permalink raw reply
* Re: Working on merged branches whilst seeing current master
From: Tim Mazid @ 2009-11-12 12:48 UTC (permalink / raw)
To: git
In-Reply-To: <20091111215727.GK27518@vidovic>
Nicolas Sebrecht-3 wrote:
>
> The 11/11/09, rhlee wrote:
>>
>> I use branches for features. I have a branch and I merged it into my
>> master
>> branch as I thought it was finished. But it turns out I wasn't and so I
>> need
>> to work on it again.
>>
>> I have made some more changes (branches and merges) on master. So what I
>> should do is checkout that branch, work on it committing along the way
>> and
>> then merge it again onto my master branch.
>>
>> However I though I am working on a feature branch I want to be also
>> working
>> from the master branch as reference.
>
> If the feature branch is merged to the mainline, it should really mean
> that the feature is ready : the feature branch life stop here. This also
> means that if you see that this feature was not as ready as you thought,
> you have to restart a _new_ feature branch off of the mainline.
>
Actually, there's no reason you couldn't just 'git reset HEAD^' once you
realise that the branch isn't ready. If you want to see the changes from
master, you could just merge that into your branch. If you just want to see
the content in master, you could use gitk or gitg, which allows you to view
files at any commit.
Personally, I merge master into my branches, test and check, and fix, then
merge the branch into master. This sometimes results in a fast-forward, if
you haven't made changes to master. If you don't like that, you can always
use the --no-ff option, though.
Good luck,
Tim.
--
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3992599.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Jan Nieuwenhuizen @ 2009-11-12 14:17 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git list
In-Reply-To: <AC99BA30-A36D-4798-8E7D-9D69EFE99D55@dbservice.com>
Op woensdag 11-11-2009 om 21:32 uur [tijdzone +0100], schreef Tomas
Carnecky:
Hi Tomas,
> It didn't tell you to copy'n'paste the whole lines to a git-config(1)
> commandline. But I do see that the output can be confusing for someone
> not familiar with the git configuration files/git-config.
Once I get this to work, I'll send a patch for it.
> I don't know the relationship between you and eddy, but usually you
> shouldn't rebase (=rewrite) eddies commits. That also means you'd have
> to live with the merge commits.
Hmm, okay.
> I see your mistake. Both the origin and eddy remote write to the same
> namespace (refs/remotes/origin/*), and that's also why you get (force
> update) below
Ah, that makes sense.
> . Change the fetch line of remote.eddy.fetch to +refs/heads/*:refs/
> remotes/eddy/*. After that both command (pull -r / pull -r eddy)
> should work (I hope).
Okay, so now I have
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "origin"]
url = git@github.com:janneke/gub.git
fetch = +refs/heads/*:refs/remotes/origin/*
# advise from git pull, using <nickname> = eddy
# branch.master.remote = <nickname>
# branch.master.merge = <remote-ref>
# remote.<nickname>.url = <url>
# remote.<nickname>.fetch = <refspec>
#[branch "master"]
# remote = eddy
# merge = refs/heads/master
[remote "eddy"]
url = http://github.com/epronk/gub.git
#use remote.eddy.fetch to +refs/heads/*:refs/remotes/eddy/*.
fetch = +refs/heads/*:refs/remotes/eddy/*
It looked promising, but still get
15:00:20 janneke@peder:~/vc/gub
$ git pull -r --verbose
From git@github.com:janneke/gub
= [up to date] lilypond-release-branch -> origin/lilypond-release-branch
= [up to date] master -> origin/master
Current branch master is up to date.
15:00:26 janneke@peder:~/vc/gub
$ git pull -r --verbose eddy
From http://github.com/epronk/gub
= [up to date] lilypond-release-branch -> eddy/lilypond-release-branch
= [up to date] master -> eddy/master
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either. Please
specify which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.master.remote = <nickname>
branch.master.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
[1]15:00:33 janneke@peder:~/vc/gub
$
After this I started to re-read git-config's man page
again. There is something strange that I do not understand
branch.<name>.merge
Defines, together with branch.<name>.remote, the upstream
branch for the given branch. It tells git-fetch/git-pull
which branch to merge and can also affect git-push (see
push.default).
this seems to imply that the merge variable here
[branch "master"]
remote = FOOBAR
merge = refs/heads/master
is somehow tied to the remote nick FOOBAR. That would
mean it is actually taken as
branch.<name>.<nickname>.merge
and also that it's impossible to specify more than one
<nickname>. That would be make nicknames unusable and
thus silly, so I cannot be right?
Thanks a lot for your continued support!
Greetings,
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
^ permalink raw reply
* [PATCH] git-pull.sh: overhaul error handling when no candidates are found
From: Jan Krüger @ 2009-11-12 14:53 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: Tomas Carnecky, git list, Junio C Hamano
In-Reply-To: <1258035449.26362.273.camel@heerbeest>
* The longish error message displayed when the user uses "git pull" but
has no remote/merge/rebase lines configured for the current branch
contains example configuration to remedy the situation... but the
example uses a rather invalid syntax, using the dotted syntax "git
config" accepts, but also "=" separators which are used in the config
file format. It also implies that this syntax is valid in git config
files. This changes the example to use valid config file syntax.
* When git pull --rebase is used, error_on_no_merge_candidates still
thinks we're trying to merge, so the resulting message talks about
merge all the time, and the function looks at the "branch.foo.merge"
setting rather than the "branch.foo.rebase" setting, and so even tends
to output the wrong message for the rebase case. This makes both the
setting verification and the message depend on the mode of operation.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
I tried to pick this apart into several patches but couldn't really
find any decent way of separating the changes. It should address all of
the confusion already identified plus some additional confusion, though.
I'll admit that the dynamification of the messages is a bit crude.
git-pull.sh | 43 ++++++++++++++++++++++++++-----------------
1 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 37f3d93..906c827 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -91,45 +91,54 @@ error_on_no_merge_candidates () {
esac
done
+ if [ true = "$rebase" ]; then
+ op_type=rebase
+ op_prep=against
+ else
+ op_type=merge
+ op_prep=with
+ fi
+
curr_branch=${curr_branch#refs/heads/}
- upstream=$(git config "branch.$curr_branch.merge")
+ upstream=$(git config "branch.$curr_branch.$op_type")
remote=$(git config "branch.$curr_branch.remote")
if [ $# -gt 1 ]; then
- echo "There are no candidates for merging in the refs that you just fetched."
+ echo "There are no candidates for using the refs that you just fetched."
echo "Generally this means that you provided a wildcard refspec which had no"
echo "matches on the remote end."
elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
echo "You asked to pull from the remote '$1', but did not specify"
- echo "a branch to merge. Because this is not the default configured remote"
+ echo "a branch to use. Because this is not the default configured remote"
echo "for your current branch, you must specify a branch on the command line."
elif [ -z "$curr_branch" ]; then
echo "You are not currently on a branch, so I cannot use any"
- echo "'branch.<branchname>.merge' in your configuration file."
- echo "Please specify which branch you want to merge on the command"
+ echo "'branch.<branchname>.$op_type' in your configuration file."
+ echo "Please specify which branch you want to use on the command"
echo "line and try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
elif [ -z "$upstream" ]; then
echo "You asked me to pull without telling me which branch you"
- echo "want to merge with, and 'branch.${curr_branch}.merge' in"
- echo "your configuration file does not tell me either. Please"
- echo "specify which branch you want to merge on the command line and"
+ echo "want to $op_type $op_prep, and 'branch.${curr_branch}.$op_type' in"
+ echo "your configuration file does not tell me either. Please"
+ echo "specify which branch you want to use on the command line and"
echo "try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
echo
- echo "If you often merge with the same branch, you may want to"
- echo "configure the following variables in your configuration"
- echo "file:"
+ echo "If you often $op_type $op_prep the same branch, you may want to"
+ echo "use something like the following in your configuration file:"
echo
- echo " branch.${curr_branch}.remote = <nickname>"
- echo " branch.${curr_branch}.merge = <remote-ref>"
- echo " remote.<nickname>.url = <url>"
- echo " remote.<nickname>.fetch = <refspec>"
+ echo " [branch \"${curr_branch}\"]"
+ echo " remote = <nickname>"
+ echo " $op_type = <remote-ref>"
+ echo " [remote \"<nickname>\"]"
+ echo " url = <url>"
+ echo " fetch = <refspec>"
echo
echo "See git-config(1) for details."
else
- echo "Your configuration specifies to merge the ref '${upstream#refs/heads/}' from the"
- echo "remote, but no such ref was fetched."
+ echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
+ echo "from the remote, but no such ref was fetched."
fi
exit 1
}
--
1.6.5.2.156.g89436
^ permalink raw reply related
* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Björn Steinbrink @ 2009-11-12 14:56 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: Tomas Carnecky, git list
In-Reply-To: <1258035449.26362.273.camel@heerbeest>
On 2009.11.12 15:17:29 +0100, Jan Nieuwenhuizen wrote:
> Op woensdag 11-11-2009 om 21:32 uur [tijdzone +0100], schreef Tomas
> Carnecky:
>
> Hi Tomas,
>
> > It didn't tell you to copy'n'paste the whole lines to a git-config(1)
> > commandline. But I do see that the output can be confusing for someone
> > not familiar with the git configuration files/git-config.
>
> Once I get this to work, I'll send a patch for it.
>
> > I don't know the relationship between you and eddy, but usually you
> > shouldn't rebase (=rewrite) eddies commits. That also means you'd have
> > to live with the merge commits.
>
> Hmm, okay.
>
> > I see your mistake. Both the origin and eddy remote write to the same
> > namespace (refs/remotes/origin/*), and that's also why you get (force
> > update) below
>
> Ah, that makes sense.
>
> > . Change the fetch line of remote.eddy.fetch to +refs/heads/*:refs/
> > remotes/eddy/*. After that both command (pull -r / pull -r eddy)
> > should work (I hope).
>
> Okay, so now I have
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [remote "origin"]
> url = git@github.com:janneke/gub.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> # advise from git pull, using <nickname> = eddy
> # branch.master.remote = <nickname>
> # branch.master.merge = <remote-ref>
> # remote.<nickname>.url = <url>
> # remote.<nickname>.fetch = <refspec>
> #[branch "master"]
> # remote = eddy
> # merge = refs/heads/master
> [remote "eddy"]
> url = http://github.com/epronk/gub.git
> #use remote.eddy.fetch to +refs/heads/*:refs/remotes/eddy/*.
> fetch = +refs/heads/*:refs/remotes/eddy/*
>
> It looked promising, but still get
>
> 15:00:20 janneke@peder:~/vc/gub
> $ git pull -r --verbose
> From git@github.com:janneke/gub
> = [up to date] lilypond-release-branch -> origin/lilypond-release-branch
> = [up to date] master -> origin/master
> Current branch master is up to date.
That used the configured defaults.
> 15:00:26 janneke@peder:~/vc/gub
> $ git pull -r --verbose eddy
> From http://github.com/epronk/gub
> = [up to date] lilypond-release-branch -> eddy/lilypond-release-branch
> = [up to date] master -> eddy/master
This one got arguments, so it didn't use defaults.
If you want "git pull" to use the "eddy" remote, then set
branch.<name>.remote to eddy, not to origin.
And as a sidenote:
Using "git pull --rebase" with more than one upstream is most of the
time a very bad idea.
Let's say we have:
A---B---C---D (master)
\ \
\ E---F---G (origin's master)
\
H---I---J (eddy's master)
Now you do "git pull --rebase origin master", which results in:
D' (master)
/
A---B---C---E---F---G (origin's master)
\
H---I---J (eddy's master)
And then you do "git pull eddy master", which will now rebase history
that is not yours:
A---B---C---E---F---G (origin's master)
\
H---I---J (eddy's master)
\
C'--E'--F'--G'--D' (master)
IOW, you get one hell of a mess.
Björn
^ permalink raw reply
* Re: Working on merged branches whilst seeing current master
From: rhlee @ 2009-11-12 14:57 UTC (permalink / raw)
To: git
In-Reply-To: <20091111215727.GK27518@vidovic>
Thanks for the help Nicolas,
That cleared up the issue a lot for me.
Nicolas Sebrecht-3 wrote:
>
>> Yes I know I probably should not be
>> working like this. My branches should be wholly independent. But I doing
>> web
>> development not kernel development so there is much less modularity and
>> branches/features have a tendency to creep into one another.
>
> This should not be the case. Modularity in the release process and the
> development strategy is not tied to "what I am developing". I'm doing
> some web development too and have no difficulty around this point.
>
Just to clarify. Do you mean that this should not be the case that you get
feature creep in branches or the fact that this happens does interfere with
your release process/development strategy.
Regards,
Richard
--
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3993313.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Tomas Carnecky @ 2009-11-12 15:03 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git list
In-Reply-To: <1258035449.26362.273.camel@heerbeest>
On Nov 12, 2009, at 3:17 PM, Jan Nieuwenhuizen wrote:
>
> Okay, so now I have
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [remote "origin"]
> url = git@github.com:janneke/gub.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> # advise from git pull, using <nickname> = eddy
> # branch.master.remote = <nickname>
> # branch.master.merge = <remote-ref>
> # remote.<nickname>.url = <url>
> # remote.<nickname>.fetch = <refspec>
> #[branch "master"]
> # remote = eddy
> # merge = refs/heads/master
> [remote "eddy"]
> url = http://github.com/epronk/gub.git
> #use remote.eddy.fetch to +refs/heads/*:refs/remotes/eddy/*.
> fetch = +refs/heads/*:refs/remotes/eddy/*
>
> It looked promising, but still get
>
> 15:00:20 janneke@peder:~/vc/gub
> $ git pull -r --verbose
> From git@github.com:janneke/gub
> = [up to date] lilypond-release-branch -> origin/lilypond-
> release-branch
> = [up to date] master -> origin/master
> Current branch master is up to date.
> 15:00:26 janneke@peder:~/vc/gub
> $ git pull -r --verbose eddy
> From http://github.com/epronk/gub
> = [up to date] lilypond-release-branch -> eddy/lilypond-
> release-branch
> = [up to date] master -> eddy/master
> You asked me to pull without telling me which branch you
> want to merge with, and 'branch.master.merge' in
> your configuration file does not tell me either. Please
> specify which branch you want to merge on the command line and
> try again (e.g. 'git pull <repository> <refspec>').
> See git-pull(1) for details.
>
> If you often merge with the same branch, you may want to
> configure the following variables in your configuration
> file:
>
> branch.master.remote = <nickname>
> branch.master.merge = <remote-ref>
> remote.<nickname>.url = <url>
> remote.<nickname>.fetch = <refspec>
>
> See git-config(1) for details.
> [1]15:00:33 janneke@peder:~/vc/gub
> $
Do you want to rebase on top of origin or eddy? It doesn't make sense
to rebase on top of both.
With git you usually develop new features in branches and then merge
the result into the master branch once it's ready. So you would use a
branch 'feature-X' and there you work on your feature. Since it's your
private/local branch, you can rebase it however you want. In the
meantime eddy has also worked on some new cool features, and now that
he's ready he told you to pull from his branch. So you 'git checkout
master; git pull eddy master' to merge his new features. Then you can
push the result into your github repo, checkout feature-X and rebase
that on top of the new origin/master. Once your feature is done, you
can checkout master, merge feature-X and push that to github.
Another reason not to rebase on top of eddy's master branch is this:
if is master is behind your master (eg. your master has commits that
his master doesn't), and you rebase on top of his master, you loose
the commits.
>
> After this I started to re-read git-config's man page
> again. There is something strange that I do not understand
>
> branch.<name>.merge
> Defines, together with branch.<name>.remote, the upstream
> branch for the given branch. It tells git-fetch/git-pull
> which branch to merge and can also affect git-push (see
> push.default).
>
> this seems to imply that the merge variable here
>
> [branch "master"]
> remote = FOOBAR
> merge = refs/heads/master
>
> is somehow tied to the remote nick FOOBAR. That would
> mean it is actually taken as
>
> branch.<name>.<nickname>.merge
>
> and also that it's impossible to specify more than one
> <nickname>. That would be make nicknames unusable and
> thus silly, so I cannot be right?
It seems like 'git pull <remote>' doesn't work. Either use 'git pull',
in which case git takes the needed info from
branch.<name>.remote/.merge, or use 'git pull <remote> <branch>' in
which case git will use the info from the commandline. It doesn't make
much sense to say 'pull from X but rebase on top of the same remote
branch name as if you'd pull from Y'.
tom
^ permalink raw reply
* Re: [PATCH] git-pull.sh: overhaul error handling when no candidates are found
From: Jeff King @ 2009-11-12 15:06 UTC (permalink / raw)
To: Jan Krüger
Cc: Jan Nieuwenhuizen, Tomas Carnecky, git list, Junio C Hamano
In-Reply-To: <20091112155310.7836c388@perceptron>
On Thu, Nov 12, 2009 at 03:53:10PM +0100, Jan Krüger wrote:
> * The longish error message displayed when the user uses "git pull" but
> has no remote/merge/rebase lines configured for the current branch
> contains example configuration to remedy the situation... but the
> example uses a rather invalid syntax, using the dotted syntax "git
> config" accepts, but also "=" separators which are used in the config
> file format. It also implies that this syntax is valid in git config
> files. This changes the example to use valid config file syntax.
Personally, I would go the other way: give them something they can cut
and paste on the command line, like:
git config branch.${curr_branch}.merge ${upstream#refs/heads/}
> + if [ true = "$rebase" ]; then
> + op_type=rebase
> + op_prep=against
> + else
> + op_type=merge
> + op_prep=with
> + fi
> +
> curr_branch=${curr_branch#refs/heads/}
> - upstream=$(git config "branch.$curr_branch.merge")
> + upstream=$(git config "branch.$curr_branch.$op_type")
Isn't branch.*.rebase a boolean value?
-Peff
^ permalink raw reply
* Re: Working on merged branches whilst seeing current master
From: Nicolas Sebrecht @ 2009-11-12 15:14 UTC (permalink / raw)
To: rhlee; +Cc: git, Nicolas Sebrecht
In-Reply-To: <1258037862366-3993313.post@n2.nabble.com>
The 12/11/09, rhlee wrote:
> Nicolas Sebrecht-3 wrote:
> >
> >> Yes I know I probably should not be
> >> working like this. My branches should be wholly independent. But I doing
> >> web
> >> development not kernel development so there is much less modularity and
> >> branches/features have a tendency to creep into one another.
> >
> > This should not be the case. Modularity in the release process and the
> > development strategy is not tied to "what I am developing". I'm doing
> > some web development too and have no difficulty around this point.
>
> Just to clarify. Do you mean that this should not be the case that you get
> feature creep in branches or the fact that this happens does interfere with
> your release process/development strategy.
I mean that the independency of the feature branches is mostly relying
on "what do I (as a developer) commit in this branch", which is really
tied to "how to write nice atomic commits" (easily reversible, etc).
This must be applicable whatever the product/software you're working on
and it is applicable for web development too.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] git-pull.sh: overhaul error handling when no candidates are found
From: Jan Krüger @ 2009-11-12 15:25 UTC (permalink / raw)
To: Jeff King; +Cc: Jan Nieuwenhuizen, Tomas Carnecky, git list, Junio C Hamano
In-Reply-To: <20091112150626.GA24848@coredump.intra.peff.net>
> Personally, I would go the other way: give them something they can cut
> and paste on the command line, like:
A matter of taste, I suppose. The user has to edit the lines anyway
since they contain placeholders.
> Isn't branch.*.rebase a boolean value?
Argh! Of course it is. Note to self: don't write patches in a hurry.
Disregard everything I said. I thought I was seeing incorrect behavior
in what Jan (N.) reported...
Jan
^ permalink raw reply
* Re: get git not to care about permissions
From: Eugene Sajine @ 2009-11-12 15:28 UTC (permalink / raw)
To: sconeman; +Cc: git
In-Reply-To: <76c5b8580911111334p76232995qbd6bf6b06d250854@mail.gmail.com>
>>
>> On Nov 9, 2009 11:06 AM, "sconeman" <schoen@bu.edu> wrote:
>>
>>
>> Hello,
>>
>> I'm trying to set up git on a NetApp drive at my school, BU. The NetApp
>> shares are configured with Windows permissions, and I forget the specifics
>> (which I can figure out if needed) about why this is the case, but basically
>> the deal is that if true UNIX permissions were to be used, Windows wouldn't
>> be able to read the drive. As such, and because we use the Kerberos
>> ticketing system, the permissions for the drive are set up such that the
>> owners (myself and my team members) have full permissions, but nobody else
>> does. Git doesn't like this and won't even create a bare repository. Is
>> there any way I can get git to ignore permissions and just do what it needs
>> to do?
>>
>> Thanks in advance for the help!
>>
>> -Matt
> --
On Wed, Nov 11, 2009 at 4:34 PM, Eugene Sajine <euguess@gmail.com> wrote:
> Hi,
>
> I had almost similar issue - bare repos in my case should be set up under
> user which only few guys are having password from. So what I did is just a
> small program which creates the bare repo locally and makes secure copy to
> this user home. All authentication is hidden from the end user. Then users
> can access their repos via git protocol. Ialso fillthe repo with some
> additional info for cgit.
>
> Eugene
BTW I'm using "git clone --bare" in this process, so if you have a
repo with working copy you can create a bare one separately, put it on
the server and then connect to it via "git remote add"
Eugene
^ permalink raw reply
* Re: [PATCH] git-pull.sh: overhaul error handling when no candidates are found
From: Jeff King @ 2009-11-12 15:28 UTC (permalink / raw)
To: Jan Krüger
Cc: Jan Nieuwenhuizen, Tomas Carnecky, git list, Junio C Hamano
In-Reply-To: <20091112162558.6b1c4a43@perceptron>
On Thu, Nov 12, 2009 at 04:25:58PM +0100, Jan Krüger wrote:
> > Personally, I would go the other way: give them something they can cut
> > and paste on the command line, like:
>
> A matter of taste, I suppose. The user has to edit the lines anyway
> since they contain placeholders.
Oh, true. I was thinking we filled them in with the right values, but of
course we don't know what those values are (if we did, we wouldn't be
bugging the user...). So ignore what I said.
> > Isn't branch.*.rebase a boolean value?
>
> Argh! Of course it is. Note to self: don't write patches in a hurry.
> Disregard everything I said. I thought I was seeing incorrect behavior
> in what Jan (N.) reported...
If it makes you feel better, the reason I noticed your error so quickly
is that I made the _exact_ same one while doing a patch in that area a
month or two ago.
-Peff
^ permalink raw reply
* Re: get git not to care about permissions
From: Matt Schoen @ 2009-11-12 15:47 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580911120728j2f9995basb554b0a493a364bf@mail.gmail.com>
Thanks for the tip, Eugene, but I'm not sure if this helps me.
I'm trying to set up the repo on a shared directory, which isn't
actually on a physical computer (NetApp is basically a
data-server-in-a-box, and as such I do not directly interface with
it). Thus, I must access the directory over the school network, which
uses Kerberos security. I think it is this restriction that is giving
git its issues.
On Thu, Nov 12, 2009 at 10:28 AM, Eugene Sajine <euguess@gmail.com> wrote:
>>>
>>> On Nov 9, 2009 11:06 AM, "sconeman" <schoen@bu.edu> wrote:
>>>
>>>
>>> Hello,
>>>
>>> I'm trying to set up git on a NetApp drive at my school, BU. The NetApp
>>> shares are configured with Windows permissions, and I forget the specifics
>>> (which I can figure out if needed) about why this is the case, but basically
>>> the deal is that if true UNIX permissions were to be used, Windows wouldn't
>>> be able to read the drive. As such, and because we use the Kerberos
>>> ticketing system, the permissions for the drive are set up such that the
>>> owners (myself and my team members) have full permissions, but nobody else
>>> does. Git doesn't like this and won't even create a bare repository. Is
>>> there any way I can get git to ignore permissions and just do what it needs
>>> to do?
>>>
>>> Thanks in advance for the help!
>>>
>>> -Matt
>> --
> On Wed, Nov 11, 2009 at 4:34 PM, Eugene Sajine <euguess@gmail.com> wrote:
>> Hi,
>>
>> I had almost similar issue - bare repos in my case should be set up under
>> user which only few guys are having password from. So what I did is just a
>> small program which creates the bare repo locally and makes secure copy to
>> this user home. All authentication is hidden from the end user. Then users
>> can access their repos via git protocol. Ialso fillthe repo with some
>> additional info for cgit.
>>
>> Eugene
>
> BTW I'm using "git clone --bare" in this process, so if you have a
> repo with working copy you can create a bare one separately, put it on
> the server and then connect to it via "git remote add"
>
> Eugene
>
>
^ permalink raw reply
* Re: get git not to care about permissions
From: Matt Schoen @ 2009-11-12 15:44 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490911112144n6837d02cw94d608bcbc74855a@mail.gmail.com>
The only output I get is:
warning: templates not found /tmp/git/share/git-core/templates
error: Unable to open
/ad/eng/courses/ec/ec464/ec464-team03/test.git/HEAD.lock for writing
ls -al in the directory gives me:
total 12
drwx------ 3 schoen root 4096 Nov 12 10:41 .
d--------- 7 root root 4096 Nov 12 10:41 ..
-rwx------ 1 schoen root 0 Nov 12 10:41 HEAD.lock
drwx------ 4 schoen root 4096 Nov 12 10:41 refs
As I understand it, because we use Kerberos, permissions on everything
must be set to 700 at most. I think the issue here comes from the
fact that git wants to use group permissions. This is my guess.
On Thu, Nov 12, 2009 at 12:44 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Wed, Nov 11, 2009 at 4:17 PM, sconeman <schoen@bu.edu> wrote:
>> does. Git doesn't like this and won't even create a bare repository. Is
>> there any way I can get git to ignore permissions and just do what it needs
>> to do?
>
> And the output from "git init --bare" is?
>
> j.
>
>
^ permalink raw reply
* [PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found
From: Jan Krüger @ 2009-11-12 16:08 UTC (permalink / raw)
To: Jeff King; +Cc: Jan Nieuwenhuizen, Tomas Carnecky, git list, Junio C Hamano
In-Reply-To: <20091112150626.GA24848@coredump.intra.peff.net>
* The longish error message displayed when the user uses "git pull" but
has no remote/merge/rebase lines configured for the current branch
contains example configuration to remedy the situation... but the
example uses a rather invalid syntax, using the dotted syntax "git
config" accepts, but also "=" separators which are used in the config
file format. It also implies that this syntax is valid in git config
files. This changes the example to use valid config file syntax.
* When git pull --rebase is used, error_on_no_merge_candidates still
thinks we're trying to merge, so the resulting message talks about
merge all the time. This makes the message depend on the mode of
operation.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
So this still uses config file syntax, but the erroneous check for
using the "rebase" setting is gone. Instead, if --rebase is in effect,
include "rebase = true" in the sample config snippet.
By the way, Jeff, it's precisely your patch that confused me into
thinking there was a bug. I sort of assumed the messages you added had
already been there in the version Jan N. is using. Stupid assumption, I
guess.
git-pull.sh | 41 ++++++++++++++++++++++++++---------------
1 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 37f3d93..315ec51 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -91,45 +91,56 @@ error_on_no_merge_candidates () {
esac
done
+ if [ true = "$rebase" ]; then
+ op_type=rebase
+ op_prep=against
+ else
+ op_type=merge
+ op_prep=with
+ fi
+
curr_branch=${curr_branch#refs/heads/}
upstream=$(git config "branch.$curr_branch.merge")
remote=$(git config "branch.$curr_branch.remote")
if [ $# -gt 1 ]; then
- echo "There are no candidates for merging in the refs that you just fetched."
+ echo "There are no candidates for using the refs that you just fetched."
echo "Generally this means that you provided a wildcard refspec which had no"
echo "matches on the remote end."
elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
echo "You asked to pull from the remote '$1', but did not specify"
- echo "a branch to merge. Because this is not the default configured remote"
+ echo "a branch to use. Because this is not the default configured remote"
echo "for your current branch, you must specify a branch on the command line."
elif [ -z "$curr_branch" ]; then
echo "You are not currently on a branch, so I cannot use any"
echo "'branch.<branchname>.merge' in your configuration file."
- echo "Please specify which branch you want to merge on the command"
+ echo "Please specify which branch you want to use on the command"
echo "line and try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
elif [ -z "$upstream" ]; then
echo "You asked me to pull without telling me which branch you"
- echo "want to merge with, and 'branch.${curr_branch}.merge' in"
- echo "your configuration file does not tell me either. Please"
- echo "specify which branch you want to merge on the command line and"
+ echo "want to $op_type $op_prep, and 'branch.${curr_branch}.merge' in"
+ echo "your configuration file does not tell me either. Please"
+ echo "specify which branch you want to use on the command line and"
echo "try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
echo
- echo "If you often merge with the same branch, you may want to"
- echo "configure the following variables in your configuration"
- echo "file:"
+ echo "If you often $op_type $op_prep the same branch, you may want to"
+ echo "use something like the following in your configuration file:"
echo
- echo " branch.${curr_branch}.remote = <nickname>"
- echo " branch.${curr_branch}.merge = <remote-ref>"
- echo " remote.<nickname>.url = <url>"
- echo " remote.<nickname>.fetch = <refspec>"
+ echo " [branch \"${curr_branch}\"]"
+ echo " remote = <nickname>"
+ echo " merge = <remote-ref>"
+ test rebase = "$op_type" &&
+ echo " rebase = true"
+ echo " [remote \"<nickname>\"]"
+ echo " url = <url>"
+ echo " fetch = <refspec>"
echo
echo "See git-config(1) for details."
else
- echo "Your configuration specifies to merge the ref '${upstream#refs/heads/}' from the"
- echo "remote, but no such ref was fetched."
+ echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
+ echo "from the remote, but no such ref was fetched."
fi
exit 1
}
--
1.6.5.2.156.g89436
^ permalink raw reply related
* Re: get git not to care about permissions
From: Thomas Rast @ 2009-11-12 16:10 UTC (permalink / raw)
To: Matt Schoen; +Cc: Jay Soffian, git
In-Reply-To: <3cf217d80911120744g5e020003rc00c460fff0bff1d@mail.gmail.com>
Matt Schoen wrote:
> error: Unable to open
> /ad/eng/courses/ec/ec464/ec464-team03/test.git/HEAD.lock for writing
>
> ls -al in the directory gives me:
> total 12
> drwx------ 3 schoen root 4096 Nov 12 10:41 .
> d--------- 7 root root 4096 Nov 12 10:41 ..
> -rwx------ 1 schoen root 0 Nov 12 10:41 HEAD.lock
At least in my current copy, this can only come from
// lock.c:1371
lockpath = mkpath("%s.lock", git_HEAD);
fd = open(lockpath, O_CREAT | O_EXCL | O_WRONLY, 0666);
if (fd < 0) {
error("Unable to open %s for writing", lockpath);
It prints an absolute path, so the open() also accesses an absolute
path (though I don't know why it insists on that).
But the above directory listing would indicate that you do not even
have permission to look inside your $(pwd) by absolute path...
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Idea for git-touch
From: Luís Sousa @ 2009-11-12 16:15 UTC (permalink / raw)
To: git
Hi all,
I have been using GIT for several time and I love it.
I normally do commits when something works or on the end of the day,
just to record what have doing. On other day, when I consider that is
done/working I do a rebase -i squashing everything on one commit. The
date of that commit will be preserved and is the date of the first
commit. Then I do a git-reset HEAD~1, git-add . and git-commit with the
same message to have the current date.
A nice functionality was a git-touch that did the commands before.
Best regards and keep the good work,
Luís Sousa
P.S.: While writing this message I realize that is easy to accomplish a
git-touch doing a bash script, but probably is a good idea to share.
^ permalink raw reply
* Re: Working on merged branches whilst seeing current master
From: rhlee @ 2009-11-12 16:49 UTC (permalink / raw)
To: git
In-Reply-To: <1258030118389-3992599.post@n2.nabble.com>
Tim Mazid wrote:
>
> Actually, there's no reason you couldn't just 'git reset HEAD^' once you
> realise that the branch isn't ready. If you want to see the changes from
> master, you could just merge that into your branch. If you just want to
> see the content in master, you could use gitk or gitg, which allows you to
> view files at any commit.
>
> Personally, I merge master into my branches, test and check, and fix, then
> merge the branch into master. This sometimes results in a fast-forward, if
> you haven't made changes to master. If you don't like that, you can always
> use the --no-ff option, though.
>
I don't think 'git reset HEAD^' would work in my case as that only goes back
one commit. I may have made many other changes on the master branch that I
want to keep.
By merging from master into your branch, like you said, you get a nice graph
view that shows what you've brought into your branch from master since you
last left off. But doesn't this goes against the idea that branches should
be independent, by bringing in changes from master?
--
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3994102.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Idea for git-touch
From: Jan Krüger @ 2009-11-12 17:01 UTC (permalink / raw)
To: Luís Sousa; +Cc: git
In-Reply-To: <4AFC348B.4000202@ualg.pt>
Hi Luís,
> [...] Then I do a git-reset HEAD~1, git-add . and git-commit with
> the same message to have the current date.
There is an existing command that does pretty much exactly that:
git commit --amend.
Jan
^ 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