* [PATCH] git-quiltimport.sh fix --patches handling
From: Andy Whitcroft @ 2007-11-12 12:07 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Pierre Habouzit
When converting git-quiltimport.sh to the new git-rev-part --parseopt
system, the handling of --patches was broken. We inadvertantly always
attempt to use '--patches' as the value.
This was introduced in the following commit:
commit e01fbf1a8f185bf6722e828286862a4122269ef7
Author: Pierre Habouzit <madcoder@debian.org>
Date: Sun Nov 4 11:31:01 2007 +0100
Migrate git-quiltimport.sh to use git-rev-parse --parseopt
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
git-quiltimport.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 56c9569..6b0c4d2 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -23,8 +23,8 @@ do
dry_run=1
;;
--patches)
- QUILT_PATCHES="$1"
shift
+ QUILT_PATCHES="$1"
;;
--)
shift
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-12 12:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsso3poo.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 11 Nov 2007, Junio C Hamano wrote:
> * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> + rebase: operate on a detached HEAD
Note: this might have a subtle bug when the last patch in the series
failed. If I was not too tired this morning (which might well have been
the case), rebase could not switch back to the branch correctly with this.
> ----------------------------------------------------------------
> [Approaching 'next']
>
> * kh/commit (Sun Nov 11 17:36:52 2007 +0000) 12 commits
> - builtin-commit: Add newline when showing which commit was created
> - builtin-commit: resurrect behavior for multiple -m options
> - builtin-commit --s: add a newline if the last line was not a S-o-b
> - builtin-commit: fix --signoff
> - git status: show relative paths when run in a subdirectory
> - builtin-commit: fix author date with --amend --author=<author>
> - builtin-commit: Refresh cache after adding files.
> - builtin-commit: fix reflog message generation
> - launch_editor(): read the file, even when EDITOR=:
> - Port git commit to C.
> - Export launch_editor() and make it accept ':' as a no-op editor.
> - Add testcase for ammending and fixing author in git commit.
>
> Dscho fixed a handful obvious glitches. I am hoping that this
> series should be in "testable" shape now. Will merge to "next"
> after giving it a final round of eyeballing.
FWIW I am running 'next'+builtin-commit+a couple of other patches I am
brewing. These issues are on my TODO list (most pressing first):
- commit --amend <file> erroneously commits other files that were
git-add'ed
- under certain circumstances (my maildir update script) does not
show newly created and deleted files anymore.
- do not rebuild the whole index when committing just one file,
instead use the old index, and then adjust it to the HEAD.
- remove "launching editor, logfile (null)" message
- forward port 6d4bbebd35e3a6e8091d7188f1c4d49af7f054e3 to builtin-commit
- when a message is given and no editor should be launched, avoid
lengthy runstatus calculation
Clarification for the "do not rebuild" thingie: ATM it seems that there
is a lengthy calculation going on, even if the index is clean and you only
passed one single filename on the command line.
> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
> - refactor fetch's ref matching to use refname_match()
> - push: use same rules as git-rev-parse to resolve refspecs
> - add refname_match()
> - push: support pushing HEAD to real branch name
>
> This changes the semantics slightly but I think it is a move in
> the right direction.
We could add a "--matching" option and output a warning when it is not
passed. I would like this pretty soon, and would not be sad if it went
into 'next' before this topic.
> * cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
> - Make builtin-tag.c use parse_options.
>
> This changes the handling of multiple -m option without much
> good reason. It should be a simple fix, once we know what we
> want. I think the existing behaviour of refusing multiple -m
> is probably the most sane at this point.
I tend to agree.
> * sb/clean (Tue Nov 6 23:18:51 2007 -0600) 1 commit
> - Make git-clean a builtin
Time is fleeting, so I could not yet look into the ambiguity problem where
help was requested.
> ----------------------------------------------------------------
> [Others]
>
> * jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
> - git-branch --with=commit
>
> I did this just for my own fun.
As I already said, I'd like this, but renamed to --containing=. In fact,
I just scrapped a script of mine to do the same, in excited expectation of
this feature.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Johannes Schindelin @ 2007-11-12 12:23 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, Theodore Tso, Git Mailing List
In-Reply-To: <20071112102412.GA24803@glandium.org>
Hi,
On Mon, 12 Nov 2007, Mike Hommey wrote:
> On Sun, Nov 11, 2007 at 11:26:10PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > > My mental model for git newbies is that they would probably be pulling
> > > from upstream repositories (so I was tempted to remove git-init from
> > > the common commands list), but they would rarely be cherry-picking or
> > > reverting other people's changes.
> >
> > I'd agree with that, but reverting and cherry-picking would also
> > be done on the commits the user builds on top of other people's
> > changes.
>
> On the other hand, cherry-picking and reverting are just the same thing,
> except one applies a reversed patch. Wouldn't it make sense to merge
> these two in one command ?
Technically, they are. That's why both of them live in builtin-revert.c.
But conceptually, they are not. At least _I_ found it hard at first, to
accept that reverting a patch really was a reverse cherry-picking.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-clean: Fix error message if clean.requireForce is not set.
From: Pierre Habouzit @ 2007-11-12 12:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List, Shawn Bohrer
In-Reply-To: <4738119F.2030901@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
On Mon, Nov 12, 2007 at 08:41:03AM +0000, Johannes Sixt wrote:
> Pierre Habouzit schrieb:
> >On Mon, Nov 12, 2007 at 08:27:35AM +0000, Johannes Sixt wrote:
> >>It was distracting to see this error message:
> >>
> >> clean.requireForce set and -n or -f not given; refusing to clean
> >>
> >>even though clean.requireForce was not set at all. This patch
> >>distinguishes
> >>the cases and gives a different message depending on whether the
> >>configuration variable is not set or set to true.
> > Note that your patch won't apply to next as is :)
>
> You mean because of the builtinification of git-clean? I was hoping that
> Shawn (Bohrer) is listening and will update his patch. ;) It has the same
> problem.
No, afaict the builtin git-clean isn't in next yet. Though the
git-rev-parse --parseopt-ification is :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Pierre Habouzit @ 2007-11-12 12:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711121203150.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 11 Nov 2007, Junio C Hamano wrote:
>
> > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> > + rebase: operate on a detached HEAD
>
> Note: this might have a subtle bug when the last patch in the series
> failed. If I was not too tired this morning (which might well have been
> the case), rebase could not switch back to the branch correctly with this.
OOOH so this was what happened to me today then. I did a rebase, there
was a commit to skip, the last one, and I ended up on a detached head.
As I didn't had my coffee yet, I assumed this was my fault and did
something stupid. So after all it seems it wasn't the case then :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] setup_git_directory: Setup cwd properly if worktree is found
From: Johannes Schindelin @ 2007-11-12 12:31 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <fcaeb9bf0711120413w180c07e1qbf1b186753593d7@mail.gmail.com>
Hi,
On Mon, 12 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> On Nov 12, 2007 6:57 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > But what about setup_git_directory_gently()? If the working tree is
> > overridden by the config, this function is still bogus, right?
>
> Hmm.. thinking a little bit more. I guess you're right because
> GIT_WORK_TREE takes precedence over core.worktree. Maybe some more bits
> for check_repository_format_version(). Tough decision because, from the
> value of inside_work_tree, we don't know if we can safely skip
> overriding inside_work_tree.
I was thinking about adding check_repository_format_version() and a check
for inside_work_tree < 0 with obvious handling in two places, probably as
a function: first, when we have a gitdirenv but no work_tree_env, and
second, at the end of _gently() when we found a git dir but only if
work_tree_env was not set.
> > As far as I see, setup_git_directory_gently() only works correctly
> > when core.worktree is _not_ set, unless GIT_WORK_TREE is set (which is
> > supposed to override the config setting). Note: I treat GIT_WORK_TREE
> > the same as --work-tree, since at that time they are identical.
> >
> > Maybe the config stuff has to move into _gently()?
>
> Well, it could be a bit more complicated because you need to know
> GIT_DIR first before reading config. I'd rather not move as _gently()
> is complicated already.
AFAICT it is not a question of complexity, but of correctness. Wouldn't
you agree that the prefix _gently() returns is wrong if we don't fix it?
Besides, it might be needed anyway if we are serious about the version
check. This check, however, would have to be done _whenever_ we found a
git directory, not only when work_tree_env is NULL.
But we could break down _gently() quite nicely. ATM it both handles the
cases when gitdirenv was set, and when it was unset. Even if those are
really two pretty different situations.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-12 12:33 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20071112122652.GC20482@artemis.corp>
Hi,
On Mon, 12 Nov 2007, Pierre Habouzit wrote:
> On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:
>
> > On Sun, 11 Nov 2007, Junio C Hamano wrote:
> >
> > > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> > > + rebase: operate on a detached HEAD
> >
> > Note: this might have a subtle bug when the last patch in the series
> > failed. If I was not too tired this morning (which might well have
> > been the case), rebase could not switch back to the branch correctly
> > with this.
>
> OOOH so this was what happened to me today then. I did a rebase, there
> was a commit to skip, the last one, and I ended up on a detached head.
> As I didn't had my coffee yet, I assumed this was my fault and did
> something stupid. So after all it seems it wasn't the case then :)
Thanks for acknowleding, and sorry for the bug.
Will work on a fix,
Dscho
^ permalink raw reply
* Re: [PATCH] setup_git_directory: Setup cwd properly if worktree is found
From: Johannes Sixt @ 2007-11-12 12:53 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <20071112112408.GA5420@laptop>
Nguyễn Thái Ngọc Duy schrieb:
> +export SAVED_WORK_DIR=$(pwd)/work
> +export GIT_DIR="$(pwd)"/repo.git
> +export GIT_CONFIG="$GIT_DIR"/config
> +export GIT_WORK_TREE="$(pwd)"/work
These are not very portable; use:
GIT_DIR="$(pwd)"/repo.git
GIT_CONFIG="$GIT_DIR"/config
GIT_WORK_TREE="$(pwd)"/work
export GIT_DIR GIT_CONFIG GIT_WORK_TREE
The first one also needs $(pwd) quoted.
-- Hannes
^ permalink raw reply
* Re: [StGit PATCH 0/5] A few small fixes
From: Karl Hasselström @ 2007-11-12 13:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <b0943d9e0711120302y385676a9o2d5ad50ee3ae2333@mail.gmail.com>
On 2007-11-12 11:02:54 +0000, Catalin Marinas wrote:
> My plan after 0.14 is to remove the implementation of add/rm etc.
> commands.
There are patches for this in kha/experimental. :-) They are on top of
David's conflict representation series, and I think there might be a
reason for that. But it was quite a while ago ...
On top of David's series, "stg resolved" should also be superfluous --
I just haven't gotten around to removing it yet.
> I'd like to keep them as just synonyms to the equivalent git
> commands which stgit would invoke (this is mainly for convenience as
> I usually type "stg" rather than "git").
OK, I can live with that. But I'd like them to be well hidden, so the
apparent command set doesn't become too large.
> BTW, I'll review this week the bugs already logged and clean as many
> as possible (help appreciated :-))
I think there might be a fair number of bugs that are still open in
the bug tracker even though they are fixed.
> and try to release 0.14 in 1-2 weeks.
All right!
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Make builtin-tag.c use parse_options.
From: Carlos Rica @ 2007-11-12 13:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kristian Høgsberg, Pierre Habouzit
In-Reply-To: <7vabpmpr9y.fsf@gitster.siamese.dyndns.org>
2007/11/10, Junio C Hamano <gitster@pobox.com>:
> Carlos Rica <jasampler@gmail.com> writes:
>
> > Also, this removes those tests ensuring that repeated
> > -m options don't allocate memory more than once, because now
> > this is done after parsing options, using the last one
> > when more are given. The same for -F.
>
> The reason for this change is...? Is this because it is
> cumbersome to detect and refuse multiple -m options using the
> parseopt API? If so, the API may be what needs to be fixed.
> Taking the last one and discarding earlier ones feels to me an
> arbitrary choice.
You can do many things with repeated options.
Here in git-tag we considered two different ways to manage them:
Concatenating values for the option and/or refusing more than one.
I found that current option-parser can do both from the client
using callbacks, as Pierre shows me, so I think it is the right way to do it.
Pierre, by default, I think that the parser should print an error
when more than one option of the same type is given,
in order to report it to the command-line user,
but make this behaviour optional for the programmer.
Specifically, I thought in this last option:
enum parse_opt_option_flags {
PARSE_OPT_OPTARG = 1,
PARSE_OPT_NOARG = 2,
PARSE_OPT_ALLOWREP = 4
};
> While I freely admit that I do not particularly find the "One -m
> introduces one new line, concatenated to form the final
> paragraph" handling of multiple -m options done by git-commit
> nice nor useful, I suspect that it would make more sense to make
> git-tag and git-commit handle multiple -m option consistently,
> if you are going to change the existing semantics. Since some
> people really seem to like multiple -m handling of git-commit,
> the avenue of the least resistance for better consistency would
> be to accept and concatenate (with LF in between) multiple -m
> options.
>
> With multiple -F, I think erroring out would be the sensible
> thing to do, but some people might prefer concatenation. I do
> not care either way as long as commit and tag behave
> consistently.
Then, Kristian, what are you willing to do in such case?
It seems easier for me to concatenate of -m and -F options, even when
both types are given. I don't know why "people" want multiple -m options,
but I think that mixing -m and -F options could be interesting for them too.
If someone know if this have been discussed and decided already,
please give me the link.
^ permalink raw reply
* [PATCH] rebase: brown paper bag fix after the detached HEAD patch
From: Johannes Schindelin @ 2007-11-12 13:11 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711121232370.4362@racer.site>
The --skip case was handled properly when rebasing without --merge,
but the --continue case was not.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 12 Nov 2007, Johannes Schindelin wrote:
> On Mon, 12 Nov 2007, Pierre Habouzit wrote:
>
> > On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin
> > wrote:
> >
> > > On Sun, 11 Nov 2007, Junio C Hamano wrote:
> > >
> > > > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> > > > + rebase: operate on a detached HEAD
> > >
> > > Note: this might have a subtle bug when the last patch in
> > > the series failed. If I was not too tired this morning
> > > (which might well have been the case), rebase could not
> > > switch back to the branch correctly with this.
> >
> > OOOH so this was what happened to me today then. I did a
> > rebase, there was a commit to skip, the last one, and I ended
> > up on a detached head. As I didn't had my coffee yet, I
> > assumed this was my fault and did something stupid. So after
> > all it seems it wasn't the case then :)
>
> Thanks for acknowleding, and sorry for the bug.
>
> Will work on a fix,
Here you are. Sorry again.
git-rebase.sh | 6 +++++-
t/t3403-rebase-skip.sh | 17 +++++++++++++++++
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 7a45e27..c9034b8 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -171,7 +171,11 @@ do
finish_rb_merge
exit
fi
- git am --resolved --3way --resolvemsg="$RESOLVEMSG"
+ head_name=$(cat .dotest/head-name) &&
+ onto=$(cat .dotest/onto) &&
+ orig_head=$(cat .dotest/orig-head) &&
+ git am --resolved --3way --resolvemsg="$RESOLVEMSG" &&
+ move_to_original_branch
exit
;;
--skip)
diff --git a/t/t3403-rebase-skip.sh b/t/t3403-rebase-skip.sh
index becabfc..657f681 100755
--- a/t/t3403-rebase-skip.sh
+++ b/t/t3403-rebase-skip.sh
@@ -38,6 +38,19 @@ test_expect_failure 'rebase with git am -3 (default)' '
test_expect_success 'rebase --skip with am -3' '
git rebase --skip
'
+
+test_expect_success 'rebase moves back to skip-reference' '
+ test refs/heads/skip-reference = $(git symbolic-ref HEAD) &&
+ git branch post-rebase &&
+ git reset --hard pre-rebase &&
+ ! git rebase master &&
+ echo "hello" > hello &&
+ git add hello &&
+ git rebase --continue &&
+ test refs/heads/skip-reference = $(git symbolic-ref HEAD) &&
+ git reset --hard post-rebase
+'
+
test_expect_success 'checkout skip-merge' 'git checkout -f skip-merge'
test_expect_failure 'rebase with --merge' 'git rebase --merge master'
@@ -49,6 +62,10 @@ test_expect_success 'rebase --skip with --merge' '
test_expect_success 'merge and reference trees equal' \
'test -z "`git diff-tree skip-merge skip-reference`"'
+test_expect_success 'moved back to branch correctly' '
+ test refs/heads/skip-merge = $(git symbolic-ref HEAD)
+'
+
test_debug 'gitk --all & sleep 1'
test_done
--
1.5.3.5.1738.g5c070
^ permalink raw reply related
* What is the idea for bare repositories?
From: David Kastrup @ 2007-11-12 13:11 UTC (permalink / raw)
To: git
Hi,
I have a repository declared as bare. Some commands treat it as such,
other's don't. For example, I get
git-diff [no complaint]
git-status
fatal: /usr/local/bin/git-status cannot be used without a working tree.
git-reset [no complaint]
git-reset --hard
HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE
git-commit
fatal: /usr/local/bin/git-commit cannot be used without a working tree.
git-add
fatal: This operation must be run in a work tree
So this is all somewhat inconsistent. What is the situation supposed
to be?
--
David Kastrup
^ permalink raw reply
* Re: What is the idea for bare repositories?
From: Bruno Cesar Ribas @ 2007-11-12 13:19 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86k5on8v6p.fsf@lola.quinscape.zz>
A bare repository is the way to publish your changes to the public.
git-daemon and http-clones use a bare repository that only contains
adminsitrative files.
>From man page
--bare Make a bare GIT repository. That is, instead of creating
<directory> and placing the administrative files in
<directory>/.git, make the <directory> itself the $GIT_DIR. This
obviously implies the -n because there is nowhere to check out
the working tree. Also the branch heads at the remote are copied
directly to corresponding local branch heads, without mapping
them to refs/remotes/origin/. When this option is used, neither
remote-tracking branches nor the related configuration variables
are created.
On Mon, Nov 12, 2007 at 02:11:58PM +0100, David Kastrup wrote:
>
> Hi,
>
> I have a repository declared as bare. Some commands treat it as such,
> other's don't. For example, I get
>
> git-diff [no complaint]
> git-status
> fatal: /usr/local/bin/git-status cannot be used without a working tree.
> git-reset [no complaint]
> git-reset --hard
> HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE
> git-commit
> fatal: /usr/local/bin/git-commit cannot be used without a working tree.
> git-add
> fatal: This operation must be run in a work tree
>
> So this is all somewhat inconsistent. What is the situation supposed
> to be?
>
> --
> David Kastrup
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Bruno Ribas - ribas@c3sl.ufpr.br
http://web.inf.ufpr.br/ribas
C3SL: http://www.c3sl.ufpr.br
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Jon Smirl @ 2007-11-12 13:53 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <1310ED7B-9DA5-47EC-8523-F609A1866384@zib.de>
On 11/12/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> On Nov 11, 2007, at 11:46 PM, Jon Smirl wrote:
>
> > On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
> >>
> >> On Nov 11, 2007, at 10:20 PM, Jon Smirl wrote:
> >>
> >>> On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
> >>>>> jonsmirl@terra:~/mpc5200b$ git remote show linus
> >>>>> * remote linus
> >>>>> URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
> >>>>> linux-2.6.git
> >>>>>
> >>>>> How do I push the definition of the linus remote repo?
> >>>>
> >>>> You can't. Remotes are local to a repository. They cannot be
> >>>> "pushed" nor will they be "cloned" or "fetched".
> >>>
> >>> Dreamhost is way slow compared to kernel.org, so it is better to
> >>> clone
> >>> from kernel.org first and then pull from dreamhost. What is the
> >>> right
> >>> sequence of commands so that a new user will end up with a kernel
> >>> they
> >>> can use 'git pull' on to get updates from dreamhost? I'll add
> >>> these to
> >>> the repo description page.
> >>>
> >>> I'm trying this locally and I can't figure out the right sequence of
> >>> git command to redirect origin from kernel.org to dreamhost.
> >>
> >> How about the following (untested sequence)
> >>
> >> mkdir linux-2.6
> >> cd linux-2.6
> >> git init
> >> git remote add linus git://git.kernel.org/pub/scm/linux/
> >> kernel/git/
> >> torvalds/linux-2.6.git
> >> git remote add origin ssh://jonsmirl1@git.digispeaker.com/~/
> >> mpc5200b.git
> >> git fetch linus
> >> git fetch origin
> >> git checkout -b master origin/master
> >>
> >> The general idea should be correct. You have a non-standard
> >> setup, so avoid git-clone.
> >
> > What should I do to standardize the setup so that 'clone/pull' will
> > work on it?
>
> Pull should work after you checked out origin/master. Pull should
> fetch from origin and merge to local master.
>
> But I don't see a way how you could use clone for your setup.
>
>
> > I created a master branch. I gave up on fighting with
> > gitweb and no branch named master.
>
> I don't understand your comment about gitweb.
At http://git.digispeaker.com/
The short log, log, tree links won't work unless master exists.
Once master is there, everything works.
>
>
> > I'd like to do this, but I can't figure out how.
> >
> > git clone linus
> > move origin to digispeaker
> > git pull
> >
> > There doesn't seem to be a simple way to redirect the origin.
>
> I don't know a simple way.
>
> Steffen
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: What is the idea for bare repositories?
From: Johannes Schindelin @ 2007-11-12 13:57 UTC (permalink / raw)
To: Bruno Cesar Ribas; +Cc: git
In-Reply-To: <20071112131927.GA1701@c3sl.ufpr.br>
Hi,
On Mon, 12 Nov 2007, Bruno Cesar Ribas wrote:
> A bare repository is the way to publish your changes to the public.
> git-daemon and http-clones use a bare repository that only contains
> adminsitrative files.
More to the point, a bare repository is one which does not have a working
directory attached.
As such, many commands do not make any sense at all, such as "git add"
(_what_ do you want to add? There is not even a working directory to work
with!), or "git commit".
Ciao,
Dscho
^ permalink raw reply
* Cloning from kernel.org, then switching to another repo
From: Jon Smirl @ 2007-11-12 13:57 UTC (permalink / raw)
To: Git Mailing List
I'd like to do this sequence, but I can't figure out how without
editing the config file. There doesn't seem to be a simple command to
move the origin.
git clone linus
move origin to digispeaker.git
git pull
What's the simplest way to do this?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Johannes Schindelin @ 2007-11-12 14:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711120557w62a9966bvb61a02a2bf9b99e9@mail.gmail.com>
Hi,
On Mon, 12 Nov 2007, Jon Smirl wrote:
> I'd like to do this sequence, but I can't figure out how without editing
> the config file. There doesn't seem to be a simple command to move the
> origin.
>
> git clone linus
> move origin to digispeaker.git
AKA "git config remote.origin.url <your-digispeaker-url-here>"
> git pull
Hth,
Dscho
^ permalink raw reply
* Re: git packs
From: bob @ 2007-11-12 14:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0711112307070.21255@xanadu.home>
On Nov 11, 2007, at 11:21 PM, Nicolas Pitre wrote:
> On Sun, 11 Nov 2007, bob wrote:
>
>> I applied the patch and these commands:
>>
>> cd rmwHtmlOld
>> rm -fr .git
>> git init
>> git config core.compression 0
>> git add .
>
> Note that I did "git config core.compression 0" simply to disable
> zlib compression altogether when creating the test repo just so it
> gets
> created faster. even then, auto-generating and cloning a 8GB test
> repository isn't particularly quick.
I wasn't sure why you used that, but figured that I should put it
in, because you did. And you are very correct that these tests
can take a very long time.
>
>> I then got the same error as before, "Bus error". Rats!
>
> Do you get that with a 32-bit or 64-bit build of Git?
On that machine, I changed the config.mak to generate nothing
but a 64-bit build. And activity monitor shows it as 64-bit
when I am running it. Also, off_t is 64 bit on regular
MacOSX and as a 64-bit program supported by the
latest MacOSX.
>
>> Then I modified your script since I do not have seq or
>> your test-genrandom.
>
> test-genrandom is built with Git. It is just not installed anywhere.
>
>> I substituted:
>>
>> dd count=XX if=/dev/random of=file_$i
>>
>> where XX is adjusted to meet dd's requirements. Also,
>
> Again I used test-genrandom instead of /dev/random or /dev/urandom
> simply because the former is much faster.
I didn't know that it existed, since I am not that familiar with the
internals and source directory for git.
>
>> I found after searching for a while, that the following
>> works just like your seq command:
>>
>> xyzzy="1 2 3 4"
>> for i in $xyzzy
>> do
>> ...
>> done
>>
>> Your script then ran flawlessly.
>
> However 'seq -w 1 2 63' should be replaced with "01 03 05 07 09 11 13
> 15" and so on up to 63, and 'seq -w 2 2 64' is "02 04 06 08 10 12 16"
> and so on.
That I missed but the files added up to quite a bit over 8gigs,
because my count calculation was off. So, I thought that it
was adequate for the testing. Based on above, it was
quite a few files less as well.
>
>> I looked through index-pack.c some more, but it is
>> very hard to figure it out without doing a lot of research
>> since there doesn't seem to be anything that describes
>> the layout of a pack. The link towards the end of the user's
>> manual doesn't work for me.
>
> Look at Documentation/technical/pack-format.txt in the Git source
> tree.
Thanks.
>
>> The difference between your test and my data is that
>> instead of having a few large files, I have 11,500 files
>> of varying sizes. On average though, the file size is
>> about 370k.
>
> Are you saying that the test repo with big files works for you but not
> your own data set?
That is correct, but you are probably correct that this is a separate
problem, because it is only occurring on the 64-bit side. The 32-bit
side is running without error.
>
> Would you please recap what your problem is?
With more testing last night, I believe that the problem on the 32-bit
side has been fixed. But the 'Bus error' on 64-bit side persists. I
agree that I was combining it and probably shouldn't have.
> With my one line patch you should not get the "serious inflate
> inconsistency" error anymore. The bus error must be another issue.
I no longer do on the 32-bit side.
>
>
> Nicolas
I am going to wait on the 64-bit problem until MacOSX 10.5 (Leopard)
settles down a bit. It has a few bugs in it. I will submit the
crashreporter
issue to Apple. Currently, I don't have the time to commit a lot to
git right
now.
As Apple comes out with new subreleases, I will retry my data.
If it doesn't get resolved after a subrelease or two, then I dig
deeper and
hopefully have more time to devote to it at that point.
Thank you, I do appreciate your help and your patience.
^ permalink raw reply
* Re: What is the idea for bare repositories?
From: David Tweed @ 2007-11-12 14:20 UTC (permalink / raw)
To: Bruno Cesar Ribas; +Cc: David Kastrup, git
In-Reply-To: <20071112131927.GA1701@c3sl.ufpr.br>
On Nov 12, 2007 1:19 PM, Bruno Cesar Ribas <ribas@c3sl.ufpr.br> wrote:
> A bare repository is the way to publish your changes to the public.
Just to mention this: an incredibly minor use, but a bare repository
is also useful for "temporary storage" on a non-case-preserving
filesystem (particularly if you don't have the authority/capability to
change the filesystem for one that is case preserving).
[I have a USB stick that I also occasionally use on Windows so
couldn't reformat. My repo doesn't have files whose names differ only
by case, but does have files with capitals somewhere. Not caring
either way about having checked out files, I initially tried to put a
standard repo on the stick and it wouldn't fast-forward when I tried
to push an update to it because some files checked out files had
"vanished". Making it a bare repository avoided the issue problem.]
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* [PATCH] status&commit: Teach them to show submodule commit summary
From: Ping Yin @ 2007-11-12 14:21 UTC (permalink / raw)
To: "git; +Cc: Ping Yin
In-Reply-To: <47382506.1090106@viscovery.net>
git status/commit just treats submodules as ordinary files when reporting status
changes. However, one may also wonder how submodules change (the commits).
This commit teaches git status/commit to additionally show commit summary of
user-cared (i.e. checked out) modified submodules since HEAD (or HEAD^ if
--amend option is on). For submodules deleted or initially added, commit summary
are not shown.
A configuration variable 'submodule.status' is used to turn this summary
behaviour on or off (default off). Also --submodule and --no-submodule options
are added.
By introducing this commit, git status will additionally give
'Submodules modified' section just before 'Untracked files' section as the
following example shows.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: sm1
# modified: sm2
# modified: sm3
# deleted: sm4
#
# Submodules modifiled: sm1 sm2 sm3
#
# * sm1 354cd45...3f751e5:
# <one line message for C
# <one line message for B
# >one line message for D
# >one line message for E
#
# * sm2 5c8bfb5...ac46d84:
# <msg
#
# * sm3 354cd45...3f751e5:
# Warn: sm3 doesn't contains commit 354cd45
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# file1
This superproject shown has modified/deleted submodules sm1 to sm4.
sm1 has commit C in HEAD and commit E in index. The history of sm1 is
--A-->B-->C (in HEAD:354cd45)
\
-->D-->E (in index:3f751e5)
The 'Submodules modified' section for sm1 shows how to change sm1 from commit C
(in HEAD) to commit E (in index): backward (<) to commit A first, and then
forward (>) to commit E.
Similar illustration for output of sm2 is omitted.
If the commit recorded in HEAD/index for a submodule is not found in the work
tree (say the submodule respository in the work tree), a warning will be issued.
Submodule sm3 falls into this case.
Commits of sm4 are not shown since it's a deleted submodule.
Signed-off-by: Ping Yin <pkufranky@gmail.com>
---
Documentation/git-commit.txt | 10 +++++
Documentation/git-status.txt | 3 +
git-commit.sh | 90 ++++++++++++++++++++++++++++++++++++++++--
3 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e54fb12..0680a57 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -139,6 +139,13 @@ but can be used to amend a merge commit.
-q|--quiet::
Suppress commit summary message.
+--submodule|--no-submodule
+ Show/Don't show commit summary for user-cared (i.e. checked out)
+ modified submodules. Summaries for submodules deleted or initial
+ added are not shown. The bool configuration variable
+ 'submodule.status' is used to control the default behaviour
+ (don't show by default).
+
\--::
Do not interpret any more arguments as options.
@@ -259,6 +266,9 @@ GIT_EDITOR environment variable, the core.editor configuration variable, the
VISUAL environment variable, or the EDITOR environment variable (in that
order).
+The bool configuration variable 'submodule.status' is also honored to
+enable/disable the submodule summary behaviour (see option --submodule).
+
HOOKS
-----
This command can run `commit-msg`, `pre-commit`, and
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 8fd0fc6..7afe6a0 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -49,6 +49,9 @@ mean the same thing and the latter is kept for backward
compatibility) and `color.status.<slot>` configuration variables
to colorize its output.
+The bool configuration variable 'submodule.status' is also honored
+to enable/disable the submodule summary behaviour (see option --submodule).
+
See Also
--------
gitlink:gitignore[5]
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..813eb4e 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -33,6 +33,65 @@ save_index () {
cp -p "$THIS_INDEX" "$NEXT_INDEX"
}
+# Show log of modified submodule (index modification since HEAD or $1)
+# $1 is the commit to be compared, default 'HEAD'
+show_module_log () {
+ cwd=$(pwd)
+ cd_to_toplevel
+
+ # get modified modules which have been checked out (i.e. cared by user)
+ modules=$(git diff --cached --name-only $1 |
+ (
+ IFS='' # handle the module name containing space or tab
+ while read name
+ do
+ git ls-files --stage "$name" | grep '^160000 ' >&/dev/null &&
+ GIT_DIR="$name/.git" git-rev-parse --git-dir >&/dev/null &&
+ echo "$name"
+ done
+ )
+ )
+
+ # TODO: quote module names containing space or tab
+ test -n "$modules" && echo -e "# Submodules modifiled: "$modules"\n#"
+ OLDIFS=$IFS
+ IFS=$'\n\r' # '\r' for mac os
+ for name in $modules
+ do
+ range=$(git diff --cached -- "$name" | sed -n '/^index.*160000$/ p' | awk '{print $2}')
+ indexone=${range#*..}
+ headone=${range%..*}
+ (
+ echo "* $name $headone...$indexone:"
+ headfail=
+ indexfail=
+ GIT_DIR="$name/.git" git-rev-parse $headone >&/dev/null || headfail='t'
+ GIT_DIR="$name/.git" git-rev-parse $indexone >&/dev/null || indexfail='t'
+ case "$headfail,$indexfail" in
+ t,)
+ echo " Warn: $name doesn't contains commit $headone"
+ ;;
+ ,t)
+ echo " Warn: $name doesn't contains commit $indexone"
+ ;;
+ t,t)
+ echo " Warn: $name doesn't contains commits $headone and $indexone"
+ ;;
+ *)
+ left=$(GIT_DIR="$name/.git" git log --pretty=format:" <%s" $indexone..$headone 2>&1)
+ right=$(GIT_DIR="$name/.git" git log --reverse --pretty=format:" >%s" $headone..$indexone 2>&1) &&
+ test -n "$left" && echo "$left"
+ test -n "$right" && echo "$right"
+ ;;
+ esac
+ echo
+ ) | sed 's/^/# /'
+ done
+ IFS=$OLDIFS
+
+ cd "$cwd"
+}
+
run_status () {
# If TMP_INDEX is defined, that means we are doing
# "--only" partial commit, and that index file is used
@@ -55,10 +114,25 @@ run_status () {
else
color=--nocolor
fi
- git runstatus ${color} \
- ${verbose:+--verbose} \
- ${amend:+--amend} \
- ${untracked_files:+--untracked}
+ if test -n "$showsubmodule"
+ then
+ git runstatus ${color} \
+ ${verbose:+--verbose} \
+ ${amend:+--amend} \
+ ${untracked_files:+--untracked} |
+ awk -v modulelog="$(show_module_log ${amend:+HEAD^})" '
+ /^# Untracked files:/ {shown=1; if (modulelog) print modulelog}
+ {print}
+ END {
+ if (!shown && modulelog) print modulelog
+ }
+ '
+ else
+ git runstatus ${color} \
+ ${verbose:+--verbose} \
+ ${amend:+--amend} \
+ ${untracked_files:+--untracked}
+ fi
}
trap '
@@ -90,6 +164,8 @@ force_author=
only_include_assumed=
untracked_files=
templatefile="`git config commit.template`"
+showsubmodule=$(git config --bool submodule.status 2>/dev/null)
+test "$showsubmodule" == "true" || showsubmodule=""
while test $# != 0
do
case "$1" in
@@ -230,6 +306,12 @@ do
--untracked-file|--untracked-files)
untracked_files=t
;;
+ --su|--sub|--subm|--submo|--submod|--submodu|--submodul|--submodule)
+ showsubmodule=t
+ ;;
+ --no-su|--no-sub|--no-subm|--no-submo|--no-submod|--no-submodu|--no-submodul|--no-submodule)
+ showsubmodule=
+ ;;
--)
shift
break
--
1.5.3.4
^ permalink raw reply related
* BUG: git-svn does not escape literal backslashes in author names.
From: Adrian Wilkins @ 2007-11-12 14:28 UTC (permalink / raw)
To: git
Recently converted a large (11,000+ revisions) repository.
We authenticate against the NT domain controller, so all our revision
authors are of the form "domain\user". (You can switch off mod_sspi
reporting the domain part, but I didn't know about this at the time,
so it continues for historical reasons.)
git-svn treats the literal backslashes in the author names as escapes.
This leads to authors like
domainkevin
domain\
ichard
I know, I should have read the manual and used my "authors" file. Bah.
I'm sure that part of the revision hash in git includes the author
name... so I guess I'm looking at another multi-day conversion. :-(
Can I suggest that you make the authors file compulsory by default as well?
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Steffen Prohaska @ 2007-11-12 14:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711121203150.4362@racer.site>
On Nov 12, 2007, at 1:21 PM, Johannes Schindelin wrote:
>> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
>> - refactor fetch's ref matching to use refname_match()
>> - push: use same rules as git-rev-parse to resolve refspecs
>> - add refname_match()
>> - push: support pushing HEAD to real branch name
>>
>> This changes the semantics slightly but I think it is a move in
>> the right direction.
>
> We could add a "--matching" option and output a warning when it is not
> passed. I would like this pretty soon, and would not be sad if it
> went
> into 'next' before this topic.
Is this the road towards
1) "git push --matching" push matching branches.
2) "git push --current" push only current branch.
3) "git push" report error if the config does not contain a Push line.
(after it reported a warning for a while).
I'd like to see this too. Unfortunately it's unlikely that I'll start
working on it before next weekend.
"--matching" would be a no-op at this time. Only a warning would be
printed
if it is missing. Right?
Steffen
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Ralf Wildenhues @ 2007-11-12 14:46 UTC (permalink / raw)
To: Ping Yin; +Cc: git
In-Reply-To: <1194877277-31777-1-git-send-email-pkufranky@gmail.com>
Hello,
A couple of portability nits:
* Ping Yin wrote on Mon, Nov 12, 2007 at 03:21:17PM CET:
[...]
> +
> + # TODO: quote module names containing space or tab
> + test -n "$modules" && echo -e "# Submodules modifiled: "$modules"\n#"
Typo: s/modifiled/modified/
Then, "echo -e" is not portable (and not used elsewhere in git), but you
can just use this instead:
test ... && { echo "# ..."; echo "#"; }
Also, it so happens you leave $modules outside quotes which will drop
multiple adjacent white spaces. Did you mean to use
echo "# Submodules modified: \"$modules\""
?
> + OLDIFS=$IFS
> + IFS=$'\n\r' # '\r' for mac os
$' is not portable (and not POSIX either). For example pdksh, OpenBSD
/bin/sh (which are both similar) will add "$" to the list of sepators
here, compare this:
$ foo=$'\n'; echo ".$foo."
.$
.
And at least some ash/dash versions will not interpret this as a newline
at all:
.$\n.
You can instead just use a literal newline:
IFS='
'
(minus the indentation). And add a literal carriage return if need be
(is that really needed on Mac OS?), though you may want to enclose that
in another pair of quotes to avoid it being "optimized" away by some
editor.
Cheers,
Ralf
^ permalink raw reply
* Re: [PATCH] Make builtin-tag.c use parse_options.
From: Pierre Habouzit @ 2007-11-12 14:52 UTC (permalink / raw)
To: Carlos Rica; +Cc: Junio C Hamano, git, Kristian Høgsberg
In-Reply-To: <1b46aba20711120509l104792ebo4ea9a51c710510f3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]
On Mon, Nov 12, 2007 at 01:09:37PM +0000, Carlos Rica wrote:
> 2007/11/10, Junio C Hamano <gitster@pobox.com>:
> > Carlos Rica <jasampler@gmail.com> writes:
> >
> > > Also, this removes those tests ensuring that repeated
> > > -m options don't allocate memory more than once, because now
> > > this is done after parsing options, using the last one
> > > when more are given. The same for -F.
> >
> > The reason for this change is...? Is this because it is
> > cumbersome to detect and refuse multiple -m options using the
> > parseopt API? If so, the API may be what needs to be fixed.
> > Taking the last one and discarding earlier ones feels to me an
> > arbitrary choice.
>
> You can do many things with repeated options.
> Here in git-tag we considered two different ways to manage them:
> Concatenating values for the option and/or refusing more than one.
> I found that current option-parser can do both from the client
> using callbacks, as Pierre shows me, so I think it is the right way to do it.
>
> Pierre, by default, I think that the parser should print an error
> when more than one option of the same type is given,
I beg to differ. It makes sense for OPTION_STRING options, but not for
other. Though you cannot always detect that.
Also note that:
(1) repeating options was already silent in many git commands, so it's
not really a regression ;
(2) for many commands it actually make sense to allow repeating (for
_BOOLEAN e.g.). And I'd argue that for OPTION_BIT it also makes
sense as well.
> in order to report it to the command-line user, but make this
> behaviour optional for the programmer. Specifically, I thought in
> this last option:
>
> enum parse_opt_option_flags {
> PARSE_OPT_OPTARG = 1,
> PARSE_OPT_NOARG = 2,
> PARSE_OPT_ALLOWREP = 4
> };
To do that you need to keep a list of the triggered commands to do
that, there is no way to achieve that reliably right now. As taking the
last one and discarding the other is the usual way for option parsers I
never saw this as a big issue.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Pierre Habouzit @ 2007-11-12 14:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711121232370.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
On Mon, Nov 12, 2007 at 12:33:19PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Pierre Habouzit wrote:
>
> > On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:
> >
> > > On Sun, 11 Nov 2007, Junio C Hamano wrote:
> > >
> > > > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> > > > + rebase: operate on a detached HEAD
> > >
> > > Note: this might have a subtle bug when the last patch in the series
> > > failed. If I was not too tired this morning (which might well have
> > > been the case), rebase could not switch back to the branch correctly
> > > with this.
> >
> > OOOH so this was what happened to me today then. I did a rebase, there
> > was a commit to skip, the last one, and I ended up on a detached head.
> > As I didn't had my coffee yet, I assumed this was my fault and did
> > something stupid. So after all it seems it wasn't the case then :)
>
> Thanks for acknowleding, and sorry for the bug.
well, shit happens, I'm running next especially to spot those :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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