* Re: [PATCHv3/RFC 4/5] gitweb: Create links leading to 'blame_incremental' using JavaScript
From: Jakub Narebski @ 2009-11-12 9:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Petr Baudis, git, Fredrik Kuivinen, Giuseppe Bilotta,
Luben Tuikov, Martin Koegler
In-Reply-To: <7vtyx0f9rd.fsf@alter.siamese.dyndns.org>
On Thu, 12 Nov 2009, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > But even if incremental blame turns out to be slower than incremental
> > blame it still has the advantage of being _incremental_. You have at
> > least some result soon.
>
> It wasn't it was slow that bothered me, but early implementations of
> incremental blame I tried didn't _appear_ as incremental. That was the
> dissapointing part.
>
> At the protocol and implementation level it certainly was feeding data
> incrementally to the browser, but the end user experience on the screen
> was "click....wait...wait...wait...voila the whole blame appears", not
> "click...trickle...trickle...trickle...ah everything is filled". The
> latter obviously is what an incremental one should be aiming for.
>
> No I haven't tried your latest code. Probably I should.
The problem with earliest versions of incremental blame _in some browsers_
was that 'onreadystatechange' event was not fired as soon as new part of
blame data was available (truth to be said the definition of this event
is a bit underspecified). That is why newer versions of interactive blame
use timer (alarm) to check every 1 second if there is something new.
Perhaps interactive blame should use 'onprogress' event instead, which is
well defined... but is in _draft_ of standard (XHR 2.0), and not yet in
established standard.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Locally manage user/branch setting files without pushing them remotely
From: Daniele Segato @ 2009-11-12 9:29 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Git Mailing List
In-Reply-To: <20091111192449.GH27518@vidovic>
On Wed, Nov 11, 2009 at 8:24 PM, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:
> This looks to _not_ be a piece of the development project. Settings used
> for the tests suites, company where you work, etc _are_ clones (from the
> abstract POV, at least) of the maintainer public repository.
>
> If you want to track changes of settings in a per-production-repo basis,
> you should do it _out_ of your main development repository. The latter
> should have a publishable template instead (eg. "user = user_login",
> "password = set_your_password").
you are probably right but even if I place this files outside my
repository I still have to modify them manually..
it's the same of having them into the repo but in .gitignore
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.
Regards,
Daniele
^ permalink raw reply
* Re: Locally manage user/branch setting files without pushing them remotely
From: Nicolas Sebrecht @ 2009-11-12 9:31 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Daniele Segato, Git Mailing List
In-Reply-To: <9accb4400911120129h54609846jac9eb3b6cb07b792@mail.gmail.com>
The 12/11/09, Daniele Segato wrote:
> On Wed, Nov 11, 2009 at 8:24 PM, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:
> > The 11/11/09, Daniele Segato wrote:
> >
> > If you want to track changes of settings in a per-production-repo basis,
> > you should do it _out_ of your main development repository. The latter
> > should have a publishable template instead (eg. "user = user_login",
> > "password = set_your_password").
>
> you are probably right but even if I place this files outside my
> repository I still have to modify them manually..
I don't understand. You'll still have to manually these files regardless
_how_ they are tracked.
> it's the same of having them into the repo but in .gitignore
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".
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.
> 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.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Eric Wong @ 2009-11-12 9:35 UTC (permalink / raw)
To: Pascal Obry; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <a2633edd0911120103y688a2b2ah2c33c47de195ee81@mail.gmail.com>
Pascal Obry <pascal@obry.net> wrote:
> Eric,
>
> > Will review the procedure for filtering branches :(
>
> A quick review does not show something obviously wrong on my side.
>
> The commit on the rewritten repo has a different sha-1 which is
> expected. So to me it seems that after a filter-branch on a git-svn
> repo it is mandatory to recreate all .rev_map*? Is that right? Is so,
> this is the missing piece in the procedure on my side.
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)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] gitk: Add ability to define an alternate temporary directory
From: David Aguilar @ 2009-11-12 9:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Sam Vilain, paulus, git
In-Reply-To: <20091112083559.GB17552@coredump.intra.peff.net>
On Thu, Nov 12, 2009 at 03:35:59AM -0500, Jeff King wrote:
> On Wed, Nov 11, 2009 at 08:44:53AM -0800, David Aguilar wrote:
>
> > gitk writes file@commit and file@commit^ to temporary files
> > and diffs them using an external diff tool.
> >
> > Shall I reroll with s/GITK_TMPDIR/TMPDIR/ ?
>
> gitk seems to use a very predictable temp filename (".gitk-tmp.$PID").
> Have you checked that you are not introducing any security holes by
> creating that predictable filename in a publicly writable tmpdir?
>
> It looks like it always tries to "mkdir" the file. Does tcl's mkdir
> function barf on an existing directory? If so, then I think we may be
> safe from the naive:
>
> tmp=.gitk-tmp.`pidof_other_users_gitk`
> mkdir $tmp
> ln -s /file/for/other/user/to/destroy /tmp/1
>
> attack. And I think we are not susceptible to races because we fail if
> the mkdir fails (instead of doing something stupid like stat followed
> by mkdir).
>
> But it has been a long time since I thought about /tmp security, so I
> may be forgetting something.
>
> -Peff
Thanks for the review.
I'm about to reroll with a new subject, "gitk: Honor TMPDIR..."
When I have more time I can switch gitk over to git-difftool
which I know is /tmp safe. I only dabble in tcl but the
docs say that mkdir does not error out when given
directories that already exist. It does error out when
given a file.
The /tmp trick would require them knowing the SHA-1 that
we're diffing and symlinking the names to paths they want
us to destroy. It seems paranoid to worry about it ;)
but since if it's a real concern than I'll try to
get to the git-difftool rework within the next two week.
I only dabble in tcl ;)
--
David
^ permalink raw reply
* [PATCH] gitk: Honor TMPDIR when viewing diffs externally
From: David Aguilar @ 2009-11-12 9:37 UTC (permalink / raw)
To: paulus; +Cc: peff, sam, git, David Aguilar
gitk's external diff fails when browsing read-only repositories.
This is due to gitk's assumption that the current directory is
always writable. By honoring TMPDIR we avoid this problem and
allow users to define the location used for temporary files.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
gitk | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index db5ec54..a065e94 100755
--- a/gitk
+++ b/gitk
@@ -3170,11 +3170,15 @@ proc flist_hl {only} {
}
proc gitknewtmpdir {} {
- global diffnum gitktmpdir gitdir
+ global diffnum gitktmpdir gitdir env
if {![info exists gitktmpdir]} {
- set gitktmpdir [file join [file dirname $gitdir] \
- [format ".gitk-tmp.%s" [pid]]]
+ if {[info exists env(TMPDIR)]} {
+ set tmpdir $env(TMPDIR)
+ } else {
+ set tmpdir [file dirname $gitdir]
+ }
+ set gitktmpdir [file join $tmpdir [format ".gitk-tmp.%s" [pid]]]
if {[catch {file mkdir $gitktmpdir} err]} {
error_popup "[mc "Error creating temporary directory %s:" $gitktmpdir] $err"
unset gitktmpdir
--
1.6.5.2.180.gc5b3e
^ permalink raw reply related
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Peter Krefting @ 2009-11-12 9:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Nicolas Sebrecht, Baz, Git Mailing List,
Johannes Schindelin, Björn Steinbrink
In-Reply-To: <7vvdhggote.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Perhaps there is some different issue at the root of this one. Why would
> anybody be tempted to say "-s ours" while running a rebase? What did the
> user want to see it do (instead of being a no-op because "ours" by
> definition ignores the tree the change is replayed from)?
The reason why I wanted it in my initial example was due to me misreading
the documentation of "ours".
My scenario is like this:
I have my web site under Git control (used to be CVS). Some parts of the web
site is updated in-place (blog comments being saved as HTML directly in the
web tree), whereas all other edits are done in clones of the repsository.
These changes are then added and committed to the checked out web tree and
pushed to the central repo.
In some cases, I wish to edit the comments in one of my clones (to remove
spam not stopped by my spam filters, for instance), but editing these risks
creating a conflict if there has been other changes in the mean time.
The web tree checkout script uses rebase to avoid introducing merge commits
every time the blog comment is updated, as it in 99 % of cases is unrelated
to any other changes found in the central repo.
In the few cases where the blog comment update from the web tree conflicts
with a change in the central repo, I want the "git pull --rebase" call to
overwrite any changes in the central repo with my changes in the web tree
(meaning that I would later have to manually re-delete the spam comments,
but I can live with that).
> It is easy to dismiss it as a user misconception and it also is tempting
> to think that it would be helped with updated description of "ours" to
> dispel that misconception, but there may be some user wish that is totally
> different from "ours merge" strategy but still can be validly labelled
> using a word "ours" by somebody who does not know the way the word "ours"
> is used in the git land, and satisfying that unknown user wish might be
> the real solution to this issue.
Yes, I am apparently looking for something that is not available in the Git
codebase yet. :-)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Björn Steinbrink @ 2009-11-12 9:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Nicolas Sebrecht, Baz, Peter Krefting,
Git Mailing List, Johannes Schindelin
In-Reply-To: <7vvdhggote.fsf@alter.siamese.dyndns.org>
On 2009.11.11 23:55:09 -0800, Junio C Hamano wrote:
> 58634db (rebase: Allow merge strategies to be used when rebasing,
> 2006-06-21) added "-m" and "-s" to rebase to solve the problem of rebasing
> against an upstream that has moved files. What the commit actually did
> was to use recursive (by default) while giving longer rope to the users by
> choosing other strategies with "-s", without making any judgement as to
> why other strategies may possibly be useful.
At least the original reason for 58634db became (partially?) moot half a
year later, thanks to 579c9bb19 "Use merge-recursive in git-am -3".
Rebase already falls back to recursive merging in am, so using rebase -m
with the recursive strategy just stops it from trying the fast path,
right?
That should probably be reflected in the man page, but honestly I have
no idea what to write there now. The note about recursive should go, but
keeping only "Use merging strategies to rebase" doesn't actually look
like it's going to be helpful in any way.
> Perhaps there is some different issue at the root of this one. Why would
> anybody be tempted to say "-s ours" while running a rebase? What did the
> user want to see it do (instead of being a no-op because "ours" by
> definition ignores the tree the change is replayed from)?
Given the few requests I've seen of it (here + #git), I'd guess that
the user wants "git rebase -s ours $up" to do either:
MB=$(git merge-base $up HEAD)
git filter-branch --parent-filter "sed -e s/$MB/$up/" -- HEAD --not $up
i.e. just re-attach things to upstream, ignoring whatever upstream did
(git-svn users seem to want something like that sometimes to be able to
dcommit. Dunno if they have some hatred against the other users of their
svn repo ;-))
Or the user wants the infamous "resolve conflicts to want I did", often
enough without thinking about what that actually means and how it can
easily lead to total crap. (Yes, I'm biased...)
Björn
^ permalink raw reply
* Re: [PATCH] gitk: Add ability to define an alternate temporary directory
From: Jeff King @ 2009-11-12 9:56 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Sam Vilain, paulus, git
In-Reply-To: <20091112093611.GA47285@gmail.com>
On Thu, Nov 12, 2009 at 01:36:13AM -0800, David Aguilar wrote:
> When I have more time I can switch gitk over to git-difftool
> which I know is /tmp safe. I only dabble in tcl but the
> docs say that mkdir does not error out when given
> directories that already exist. It does error out when
> given a file.
OK, then I think we would be vulnerable, as I can make a .gitk-tmp.$PID
directory owned by me that your gitk will happily use.
> The /tmp trick would require them knowing the SHA-1 that
> we're diffing and symlinking the names to paths they want
> us to destroy. It seems paranoid to worry about it ;)
But the SHA-1 is not hard to guess[1], as you have a finite,
easily-enumerable list of them in your repository. :) One thing that
does make it harder is that gitk actually checks to see if a file is
already there before creating it (presumably not for security, but for
efficiency). Which means I can't just pre-seed a trap and wait for you
to run gitk; I have to actually race you and create the file between
your "file exists" check and the eventual "git show $filename >$output"
which will hose it.
Probably I can win that race given a sufficient number of attempts, but
attempts are made at a human pace. So in practice it's probably pretty
hard to exploit. Still, I'd rather see it done properly on principle.
Then we _know_ we're not missing some trick, and there's no chance of a
later code change increasing an attacker's probability of success.
-Peff
[1] I was also going to suggest a social-engineering attack, like "hey,
I screwed up my repository. Can you take a look?" Then you don't need to
guess the SHA-1, as you convince the victim to look at a specific one.
But that attack is already much, much worse: we respect items in
.git/config regardless of whether it is owned by the running user. So it
is not actually safe to "cd ~other_user/project && git diff".
^ permalink raw reply
* [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
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