* Re: FFmpeg considering GIT
From: Linus Torvalds @ 2007-05-05 22:18 UTC (permalink / raw)
To: Karl Hasselstr?m, Paul Mackerras, Junio C Hamano
Cc: Carl Worth, Michael Niedermayer, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0705051019580.3819@woody.linux-foundation.org>
On Sat, 5 May 2007, Linus Torvalds wrote:
>
> This patch may be worth applying regardless, since there is really no real
> reason to use "git rev-list". In fact, I really like the ability to say
>
> gitk --stat
>
> and have the diffstat output visible in the commit window automatically ;)
Btw, testing this a bit more actually shows what I would consider a real
buglet in "git log --boundary": the option would be honoured only if
"left-right" was enabled.
This patch fixes "git log --boundary" to actually show the "-" in front of
a commit name regardless of whether you _also_ asked for left-right.
(It also shows that my "gitk" patch was incorrectly getting the commit
name from character 6 onward, even though it should have been 7, but I'll
also try to make gitk understand the "<" and ">" markers, and make it
possible to say
gitk --left-right a...b
and have the commits colored appropriately. That would be cool, but it
might need more tcl/tk knowledge than I actually possess).
Linus
---
diff --git a/log-tree.c b/log-tree.c
index c679324..4bef909 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -244,10 +244,10 @@ void show_log(struct rev_info *opt, const char *sep)
stdout);
if (opt->commit_format != CMIT_FMT_ONELINE)
fputs("commit ", stdout);
- if (opt->left_right) {
- if (commit->object.flags & BOUNDARY)
- putchar('-');
- else if (commit->object.flags & SYMMETRIC_LEFT)
+ if (commit->object.flags & BOUNDARY)
+ putchar('-');
+ else if (opt->left_right) {
+ if (commit->object.flags & SYMMETRIC_LEFT)
putchar('<');
else
putchar('>');
^ permalink raw reply related
* Re: [PATCH v3] Support ent:relative_path
From: Martin Waitz @ 2007-05-05 21:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Johannes Schindelin, Dana How, Git Mailing List
In-Reply-To: <7vy7k3hvog.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
hoi :)
On Sat, May 05, 2007 at 01:17:35PM -0700, Junio C Hamano wrote:
> > we could also introduce "<tree-ish>/<path>" for absolute path entries.
>
> When you name the tree-ish with usual "branch name", where does
> the branch name end and pathname start? What happens when there
> is an ambiguity, and how costly to detect such an ambiguity to
> begin with?
well, if you know that it starts with a tree-ish there is no
ambiguity as there can't be any "a/b" tree-ish if there already is one
named "a". But Alex is right, it can be confused with an relative
path if e.g. git-log is used without "--".
But for submodules I'd really like the / syntax.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Add colour support in rebase and merge tree diff stats output.
From: James Bowes @ 2007-05-05 20:48 UTC (permalink / raw)
To: git, junkio
The rebase and merge commands used diff-tree to display the summary stats of
what files had changed from the operation. diff-tree does not read the
diff ui configuration options, so the diff.color setting was not used.
Have rebase and merge call diff rather than diff-tree, which does read the
diff ui options.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
---
I'm not sure if setting GIT_PAGER to '' is the best way to disable the pager
in this case (though I'm quite certain it should be disabled), but it does
the trick. Perhaps there should be a git --no-pager option?
git-merge.sh | 3 ++-
git-rebase.sh | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index 7ebbce4..351676f 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -90,7 +90,8 @@ finish () {
?*)
case "$no_summary" in
'')
- git-diff-tree --stat --summary -M "$head" "$1"
+ # We want color (if set), but no pager
+ GIT_PAGER='' git-diff --stat --summary -M "$head" "$1"
;;
esac
;;
diff --git a/git-rebase.sh b/git-rebase.sh
index 2dc2c4f..61770b5 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -307,7 +307,8 @@ fi
if test -n "$verbose"
then
echo "Changes from $mb to $onto:"
- git-diff-tree --stat --summary "$mb" "$onto"
+ # We want color (if set), but no pager
+ GIT_PAGER='' git-diff --stat --summary "$mb" "$onto"
fi
# Rewind the head to "$onto"; this saves our current head in ORIG_HEAD.
--
1.5.2.rc1.741.g85102-dirty
^ permalink raw reply related
* Re: [PATCH v3] Support ent:relative_path
From: Alex Riesen @ 2007-05-05 20:37 UTC (permalink / raw)
To: Martin Waitz
Cc: Shawn O. Pearce, Johannes Schindelin, Dana How, Junio C Hamano,
Git Mailing List
In-Reply-To: <20070505193214.GD30511@admingilde.org>
Martin Waitz, Sat, May 05, 2007 21:32:14 +0200:
> we could also introduce "<tree-ish>/<path>" for absolute path entries.
"012345/abc/def"
Is it a relative path, or a tree-ish + absolute path?
^ permalink raw reply
* Re: [PATCH v3] Support ent:relative_path
From: Junio C Hamano @ 2007-05-05 20:17 UTC (permalink / raw)
To: Martin Waitz
Cc: Shawn O. Pearce, Johannes Schindelin, Dana How, Git Mailing List
In-Reply-To: <20070505193214.GD30511@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> we could also introduce "<tree-ish>/<path>" for absolute path entries.
When you name the tree-ish with usual "branch name", where does
the branch name end and pathname start? What happens when there
is an ambiguity, and how costly to detect such an ambiguity to
begin with?
^ permalink raw reply
* Re: [RFC PATCH] Rename "bury" back to "sink".
From: Yann Dirson @ 2007-05-05 20:13 UTC (permalink / raw)
To: Jakub Narebski, Catalin Marinas; +Cc: git
In-Reply-To: <f1gf8i$p52$1@sea.gmane.org>
The whole debate around burying, sinking and floating patches made me
think a bit more about this. So we have:
float: move specified patches to top of stack
bury/float: move specified patches to bottom of stack or any place
in the stack identified by a nearby patch
All in all, that all "move specified patches to a specified place".
So wouldn't it be possible to end the debate by merging those commands
into a single "stg move" command ?
Side note about the "stg move" name: yes it could possible to mistake it
for "move file" (especially as we don't have "stg mv"). My current
state of mind would be to drop add/rm/cp from stgit, and move the "stg
cp" logic to a new git-cp command. This way, stgit would just be
about handling series of patches, with git being used for the
working-copy. Any opinions on this ?
Now to the new command. We could have something like:
stg move -t base <patches> <=> stg sink <patches>
stg move -t <patch> <patches> <=> stg sink -t <patch> <patches>
stg move -t current <patches> <=> stg float <patches>
Note the introduction of a new "curent" stg_id for the tip of the
stack.
The semantics of the arg to -t would be something like "the limit
between the patches that will end up below <patches> and those that
will end up above". I suppose "-t current" should be the default, so
it may not even be necessary to expose "current" to the command-line.
The "conceptual algorithm" would be:
1. stg pop <patches>
2. stg push <patches>
3. stg goto "where I was"
"-s [<series>]" would be allowed as an alternative to <patches>, so
"move" would be a strict superset of "float".
By default, consistently with "float", the <patches> (and hence
everything originally under the target point) will end up applied if
the target of the move was "within $applied" (ie. an applied patch or
"current" - something we could call "below the surface", hi float and
sink ;), and all patches that were applied (ie. those between the
target and the former tip) will end up being reapplied, consistently
with "sink".
If the target point is in $unapplied, then the command will be
equivalent to "stg pop <patches>" with those patches reordered at the
target (ie. no need to really execute steps 2 and 3 above). That's no
rocket science, but a useful I have already missed, eg. when I just
want to move the patches away from my working set (nowadays we could
hide them, but that may not be always adequate).
A --dont-come-back flag of some sort will skip step 3 of the
conceptual algorithm above. When the target will be in $applied, it
will be the equivalent of "sink --nopush". When the target is in
$unapplied, we will "goto <last of <patches>>" after reorering the
unapplied patches. Never missed this one till now, but who knows,
this side-effect might come handy.
Opinions ?
--
Yann.
PS: this RFC is known as "bury sink and float" ;)
^ permalink raw reply
* Re: [PATCH v3] Support ent:relative_path
From: Martin Waitz @ 2007-05-05 19:32 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Schindelin, Dana How, Junio C Hamano, Git Mailing List
In-Reply-To: <20070505033039.GD16538@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
On Fri, May 04, 2007 at 11:30:39PM -0400, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Fri, 4 May 2007, Dana How wrote:
> >
> > > Most commands accept relative paths, but this is
> > > not true of arguments in ent:path format. This
> > > patch makes all of the following git-show commands
> > > work in the git source tree (not just the first):
> > > % cd xdiff
> > > % git-show v1.5.2-rc0:xdiff/xemit.h
> > > % git-show v1.5.2-rc0:./xemit.h
> > > % git-show v1.5.2-rc0:../sha1_name.c
> >
> > ACK.
>
> Double ACK. I'm in complete agreement with every point Dscho has
> made in this thread, even if I haven't quoted it. ;-)
>
> I *really* do not want to see "<tree-ish>:<path>" to mean include
> the current prefix, *especially* when a bare repository is involved.
we could also introduce "<tree-ish>/<path>" for absolute path entries.
This would make a lot of sense for submodules:
git show "<tree-ish>/path/to/submodule/path/inside/submodule
with only : it would not look that nice ;-)
OK, we could simply say that submodules are special and that you
don't have to use : to separate a commit (the submodule entry) from
the path inside.
aside from that I would also really like to have both absolute and
relative ways to name objects.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] simple submodule checkout support
From: Martin Waitz @ 2007-05-05 19:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Add the ability to move a submodule to a commit which is referenced by a
new supermodule version.
This is not yet a full submodule checkout support -- you can't checkout any
commit which is not yet available in the submodule object database.
This means you can't create new submodules yet.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
.gitignore | 1 +
Makefile | 2 +-
entry.c | 16 +++++++++++-----
git-dirlink-checkout.sh | 27 +++++++++++++++++++++++++++
t/t3041-subprojects-checkout.sh | 39 +++++++++++++++++++++++++++++++++++++++
5 files changed, 79 insertions(+), 6 deletions(-)
create mode 100644 git-dirlink-checkout.sh
create mode 100755 t/t3041-subprojects-checkout.sh
diff --git a/.gitignore b/.gitignore
index 4dc0c39..8436a83 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,6 +37,7 @@ git-diff
git-diff-files
git-diff-index
git-diff-tree
+git-dirlink-checkout
git-describe
git-fast-import
git-fetch
diff --git a/Makefile b/Makefile
index 2fea115..fcd0125 100644
--- a/Makefile
+++ b/Makefile
@@ -196,7 +196,7 @@ SCRIPT_SH = \
git-merge-one-file.sh git-mergetool.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh \
git-repack.sh git-request-pull.sh git-reset.sh \
- git-sh-setup.sh \
+ git-sh-setup.sh git-dirlink-checkout.sh \
git-tag.sh git-verify-tag.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
diff --git a/entry.c b/entry.c
index 82bf725..6e85e81 100644
--- a/entry.c
+++ b/entry.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "blob.h"
+#include "run-command.h"
static void create_directories(const char *path, const struct checkout *state)
{
@@ -79,6 +80,13 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
{
int fd;
long wrote;
+ const char *dirlink_checkout[] = {
+ "dirlink-checkout", path, sha1_to_hex(ce->sha1), NULL
+ };
+ struct child_process cmd = {
+ .argv = dirlink_checkout,
+ .git_cmd = 1
+ };
switch (ntohl(ce->ce_mode) & S_IFMT) {
char *buf, *new;
@@ -148,7 +156,7 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
case S_IFDIRLNK:
if (to_tempfile)
return error("git-checkout-index: cannot create temporary subproject %s", path);
- if (mkdir(path, 0777) < 0)
+ if (run_command(&cmd) != 0)
return error("git-checkout-index: cannot create subproject directory %s", path);
break;
default:
@@ -192,10 +200,8 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
* just do the right thing)
*/
unlink(path);
- if (S_ISDIR(st.st_mode)) {
- /* If it is a gitlink, leave it alone! */
- if (S_ISDIRLNK(ntohl(ce->ce_mode)))
- return 0;
+ if (S_ISDIR(st.st_mode) &&
+ access(mkpath("%s/.git/HEAD", path), R_OK)!=0) {
if (!state->force)
return error("%s is a directory", path);
remove_subtree(path);
diff --git a/git-dirlink-checkout.sh b/git-dirlink-checkout.sh
new file mode 100644
index 0000000..2e63970
--- /dev/null
+++ b/git-dirlink-checkout.sh
@@ -0,0 +1,27 @@
+#!/bin/sh -e
+
+USAGE="<dirlink-path> <new-ref>"
+
+path="$1"
+sha1="$2"
+
+test -n "$sha1" || usage
+unset GIT_DIR
+
+if test ! -d "$path/.git"; then
+ mkdir "$path"
+ cd "$path"
+ # FIXME talk about what the user can do here
+ echo "This git submodule has not been populated yet." > README.git
+ exit 0
+fi
+
+cd "$path"
+. git-sh-setup
+
+if git rev-parse --verify "$sha1" >/dev/null 2>&1; then
+ git checkout "$sha1"
+else
+ # FIXME try to fetch it
+ echo >&2 "Cannot checkout $sha1 for $path."
+fi
diff --git a/t/t3041-subprojects-checkout.sh b/t/t3041-subprojects-checkout.sh
new file mode 100755
index 0000000..4b3cea9
--- /dev/null
+++ b/t/t3041-subprojects-checkout.sh
@@ -0,0 +1,39 @@
+#!/bin/sh
+
+test_description='submodule checkout'
+. ./test-lib.sh
+
+test_expect_success 'submodule creation' \
+ '(mkdir A && cd A &&
+ git init &&
+ echo 1 > a &&
+ git add a &&
+ git commit -m "create submodule" || exit $? )'
+
+test_expect_success 'Super module creation' \
+ 'git add A &&
+ git commit -m "supermodule creation" &&
+ git branch one'
+
+test_expect_success 'submodule change' \
+ '(cd A &&
+ echo 2 > a &&
+ git add a &&
+ git commit -m "create submodule" || exit $? )'
+
+test_expect_success 'supermodule change' \
+ 'git add A &&
+ git commit -m "supermodule creation"'
+
+test_expect_success 'supermodule switching branch' \
+ 'git checkout one &&
+ echo 1 > expected &&
+ git diff expected A/a'
+
+test_expect_success 'supermodule reset' \
+ 'git reset --hard master &&
+ echo 2 > expected &&
+ git diff expected A/a'
+
+
+test_done
--
1.5.1.2.247.gaef5a
--
Martin Waitz
^ permalink raw reply related
* [PATCH] Documentation: fix typo in git-remote.txt
From: James Bowes @ 2007-05-05 18:23 UTC (permalink / raw)
To: git, junkio
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
---
Documentation/git-remote.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index a9fb6a9..3dde713 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -40,7 +40,7 @@ With `-t <branch>` option, instead of the default glob
refspec for the remote to track all branches under
`$GIT_DIR/remotes/<name>/`, a refspec to track only `<branch>`
is created. You can give more than one `-t <branch>` to track
-multiple branche without grabbing all branches.
+multiple branches without grabbing all branches.
+
With `-m <master>` option, `$GIT_DIR/remotes/<name>/HEAD` is set
up to point at remote's `<master>` branch instead of whatever
--
1.5.2.rc1.740.gc9ba5
^ permalink raw reply related
* Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)
From: Alex Riesen @ 2007-05-05 18:03 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200705051449.45447.johan@herland.net>
Johan Herland, Sat, May 05, 2007 14:49:42 +0200:
> Can you categorically say that there is no use for the following output?
> (even if you need to pass an option to "git blame" to get it):
> ====
> ^bb0203a (User A 2007-05-05 12:25:44 +0200 1) foo
> ^bb0203a (User A 2007-05-05 12:25:44 +0200 1) bar
> ^bb0203a (User A 2007-05-05 12:25:44 +0200 3) baz
> ====
Assuming a repo which has 50% of all commits - reverts (just because
someone could not be bothered to learn to use rebase, format-patch
and git-am before sending things upstream) I would use the exact
wording I used before. I'd say "it's dangerous" now. It hides the
mess this repo is.
> > It's useless.
>
> Maybe. At least some of the fields I proposed are probably useless. But
> I don't think we should throw away the core idea unless we can show
> that _all_ fields are useless.
Just think of something you actually _can_ use. Implement it and try.
And than, if you are convinced it actually is useful, try it on your
friends. And after them, if you're still alive, try using it with old
git (like 1.4 from Debian and Ubuntu).
^ permalink raw reply
* Re: [PATCH] Make --color available to git-status
From: Johannes Schindelin @ 2007-05-05 17:58 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <11783866694076-git-send-email-Matthieu.Moy@imag.fr>
Hi,
On Sat, 5 May 2007, Matthieu Moy wrote:
> Git has a nice colored output for status, using
>
> $ git runstatus --color
>
> However, this --color is not made available to git-status itself.
AFAIR there have been attempts to enable this by default, when git-status
is run interactively (i.e. its output is not piped). However, this proved
to be remarkably complex, given that the output of runstatus _is_ piped.
IMHO the proper solution would be to go the full nine yards, and teach
runstatus about the remaining parts of git-status. Then, automatic color
works automatically.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 4/5] Add --remote option to send-pack
From: Daniel Barkalow @ 2007-05-05 17:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6pvln89.fsf@assigned-by-dhcp.cox.net>
On Sat, 5 May 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > Wouldn't it be better to to this as:
> >
> > [remote "origin"]
> > url = git.kernel.org:/pub/scm/git/git.git/
> > [branch "master"]
> > remote = origin
> > merge = refs/heads/master
>
> As I am likely to pull from other people, and I happen to expect
> the old fashioned "git pull gfi" without explicit refspec on the
> command line to get the first Pull: line from remotes file to
> tell which one to merge from, I am in favor of _not_ having that
> [branch "master"] stuff in my repository.
>
> remote.*.fetch is about what remote branches are fetched;
> tracking may or may not happen as a side effect. What I do with
> the resulting .git/FETCH_HEAD is my business and branch.*.merge
> should _not_ be the only way to access it.
Ah, okay. So FETCH_HEAD gets: (1) if something is specified on the
command line, that; (2) if there is a branch.*.merge, that; (3) the first
refspec (without a *?) listed in remote.*.fetch. Right?
> There are a few improvements we probably would want.
>
> One is the interaction between the config "fetch =..." refspecs
> and the command line ones. Currently the rule is:
>
> - If you do not say refspecs on the command line, fetch config
> (or Pull: lines from remotes/* file) are used.
>
> - If you do have refspecs on the command line, fetch config are
> not used (they are ignored).
>
> Which is fine when we talk about "git fetch", but if you _are_
> using remote tracking, and if you are running "git fetch" as an
> implementation detail of running "git pull" (IOW, you said "git
> pull origin next"), it is less than optimum. Instead of "only
> fetch 'next' without tracking and then merge it", we would
> certainly want "fetch to track everything as usual, and then
> merge 'next' instead of what is usually merged".
I think that might be confusing; I'd expect that the tracking for next
would be updated, but the tracking for other heads wouldn't. I'm not sure
I'd ever actually complain about origin/master being more up-to-date than
can be intuitively explained, but I don't think a "git pull origin next"
would make me expect origin/master to be up-to-date right after. So I'd
say, "only fetch 'next'; if you track 'next' normally, update that."
On the other hand, I've been doing a lot of "git diff origin all-my-work"
and removing hunks I don't want to send, and this makes the implicit
assumption that origin == merge_base(origin, all-my-work), which is true
only because I merge origin whenever I fetch it.
> Another thing is that which branch is merged into the current
> branch should not be a function of the current branch, as the
> current configuration mechanism suggests. The current way maps
> the current branch to "which repository's which branch". In
> addition to that, I think it should be a function of ("current
> branch", "remote repository") pair. IOW, allow you to say "If I
> pull from this remote without saying which one to merge, merge
> that branch. If I pull from this other remote, merge that other
> branch". Something like:
>
> [branch "master"]
> ; Use this when "git pull" did not say which remote
> remote = origin
>
> ; Use this when "git pull origin" did not say which
> ; branch(es) to merge
> merge = refs/heads/master
> ; the above should be a synonym for
> ; merge = refs/heads/master for origin
>
> ; "git pull fast-import" while on my "master"
> ; would merge 'for-junio' branch there.
> merge = refs/heads/for-junio for fast-import
>
> ; similarly, but use subtree strategy.
> merge = refs/heads/for-junio with subtree for git-gui
>
> [remote "origin"]
> url = git://git.kernel.org/pub/scm/git/git.git/
> fetch = refs/heads/*:remotes/origin/*
> [remote "fast-import"]
> url = git://repo.or.cz/git/fastimport.git/
> fetch = refs/heads/*:remotes/gfi/*
> [remote "git-gui"]
> url = git://repo.or.cz/git-gui.git/
> fetch = refs/heads/*:refs/remotes/git-gui/*
I think this is a good feature, but maybe the syntax should be:
merge = fast-import refs/heads/for-junio
since the remote name is user-chosen, arbitrary, and has to be typed on
the command line, and therefore people won't put in spaces, and "git fetch
fast-import refs/heads/for-junio" is what you'd type on the command line
that this abbreviates, so it's intuitive.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git branch bug
From: Johannes Schindelin @ 2007-05-05 17:54 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705051942550.14963@bianca.dialin.t-online.de>
Hi,
On Sat, 5 May 2007, Guido Ostkamp wrote:
> > On Sat, 5 May 2007, Guido Ostkamp wrote:
> >
> > > $ mkdir test
> > > $ cd test
> > > $ git init
> > > Initialized empty Git repository in .git/
> > > $ git branch experimental
> > > fatal: Not a valid object name: 'master'.
> > >
> > > So, it seems it is not possible to create a named branch on an empty
> > > repository.
> >
> > Actually, it is not possible to branch from a non-existing branch. So,
> > this is somewhat expected from my POV.
>
> From a git beginners point of view, I would expect that the 'master'
> branch is automatically created when performing the 'git init'. Why is
> this not the case?
Well, one side of the branch _is_ created. But you have to provide initial
content, to make it a proper branch, from which you can actually branch
off.
Having said that, and having read Daniels mail, I agree that this
behaviour should be changed, along with the behaviour of "git checkout -b
<branch>" in a fresh repo.
It might be the illogical thing, to allow branching of a
yet-to-be-initialised branch, but it does not hurt either.
Ciao,
Dscho
^ permalink raw reply
* Re: 'upstream' branches.
From: David Woodhouse @ 2007-05-05 17:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070505174416.GA2898@steel.home>
On Sat, 2007-05-05 at 19:44 +0200, Alex Riesen wrote:
> David Woodhouse, Sat, May 05, 2007 14:29:26 +0200:
> > [remote "origin"]
> > url = ssh://git.infradead.org/~/public_git/foo-2.6.git
> > fetch = +refs/heads/*:refs/remotes/origin/*
> > fetch = +refs/heads/mtd:refs/heads/mtd
> > fetch = +refs/heads/linus:refs/heads/linus
>
> These pluses request overwriting of the local reference even if it has
> more commits than the remote ("is newer"). Are you sure you want that?
>
> > What I have at the moment isn't ideal because I think pulling from the
> > 'mtd' tree will fail if the 'linus' branch there is older than the local
> > clone's 'linus' branch. But it mostly works.
> >
> > Is there a better way?
>
> I would just remove the pluses. git-fetch will say that the branch is
> already up-to-date, if the local branch already has everything the
> remote has.
Then after I pull from Linus' tree, I can't pull from the mtd tree -- it
complains that the 'linus' branch there can't be fast-forwarded, and
refuses to pull the 'master' branch.
I think what I actually want is an 'only fast-forward, but don't error
if you can't' option.
--
dwmw2
^ permalink raw reply
* Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)
From: Johan Herland @ 2007-05-05 12:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070504221152.GF4033@steel.home>
[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]
On Saturday 05 May 2007, Alex Riesen wrote:
> Johan Herland, Fri, May 04, 2007 13:53:10 +0200:
> > As for "Reverts", the commit pointed to should already be in your
> > history, since you cannot revert something that hasn't already been
> > applied at an earlier point in your history. In other words, the
> > reverted commit will automatically be included in your "git gc
> > --prune" or "git clone" regardless of the "Reverts" fields, since
> > "Reverts" can only point to an ancestor.
>
> So it becomes useless after rebase
Only if rebase also rebases the commit pointed to by "Reverts" (the
reverted commit). And even in that case, it should be possible for
rebase to detect the "Reverts" relationship and rewrite it properly,
or - if people want to - skip both the reverted and the reverting
commit in the rebase process.
> > As for "Cherry-Pick", it's a fairly weak relationship that
> > shouldn't affect anything except to give a hint to merge, blame,
> > and similar tools.
>
> In which case, just put it in the message part of commit (in fact, it
> was there for some time. And was mostly useless, and got dropped).
Ok. If merging branches which have had cherry-picks between them is such
a rare occurrence that there is no point in adding hints for merge (to
do better conflict resolution), blame (to see who _really_ wrote the
piece of code that was cherry-picked by someone else), etc. then there
is indeed no justification for the "Cherry-Pick" header field.
> And how exactly do you think the tools _can_ use this hint?
> Especially merge, which should be absolutely certain about what
> inputs and hints gets.
When merging two branches where one branch has a commit that is later
reverted, and the other branch has cherry-picked the first/reverted
commit, but not the second/reverting: With these hints, git can now ask
the user a more intelligent question like "The following commit was
reverted in one of the branches. Do you want to keep it or revert it?".
The current alternative seems to be to auto-choose one or the other (in
my testing, the reverting commit was dropped in the merge). Will git
always make the correct decision? If git is always correct, then what I
suggest is obviously useless.
> And what use is it for blame? How do you prioritze the hint? Is it
> more important than the history (which describes each and every
> line), or less? If the hint is more important, than how (and how
> often) do you tell the user that the hint was not found (because the
> commit is long pruned) and the tool switched back to looking into
> history.
Consider the following scenario:
====
$ mkdir test
$ cd test
$ git init
Initialized empty Git repository in .git/
$ git config user.name "User A"
$ cat >f <<\EOF
foo
bar
baz
EOF
$ git add f && git commit -m "User A: foo, bar, baz"
Created initial commit bb0203aabb4936d95dca30f946cb1d849df59f24
1 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 f
$ git config user.name "User B"
$ cat >f <<\EOF
foo
barf
baz
EOF
$ git commit -a -m "User B: bar -> barf"
Created commit 5ced0ccaba0bf4a982dc2cdd792a1a0e7b1883eb
1 files changed, 1 insertions(+), 1 deletions(-)
$ git config user.name "User C"
$ git revert HEAD
Created commit 38da1083ae4677000f8bb70729f474f358c71a3e
1 files changed, 1 insertions(+), 1 deletions(-)
====
At this point, what output do we _really_ want from "git blame f"?
Currently we get:
====
^bb0203a (User A 2007-05-05 12:25:44 +0200 1) foo
38da1083 (User C 2007-05-05 12:28:00 +0200 2) bar
^bb0203a (User A 2007-05-05 12:25:44 +0200 3) baz
====
Can you categorically say that there is no use for the following output?
(even if you need to pass an option to "git blame" to get it):
====
^bb0203a (User A 2007-05-05 12:25:44 +0200 1) foo
^bb0203a (User A 2007-05-05 12:25:44 +0200 1) bar
^bb0203a (User A 2007-05-05 12:25:44 +0200 3) baz
====
> It's useless.
Maybe. At least some of the fields I proposed are probably useless. But
I don't think we should throw away the core idea unless we can show
that _all_ fields are useless.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git branch bug
From: Guido Ostkamp @ 2007-05-05 17:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705051841200.4015@racer.site>
> On Sat, 5 May 2007, Guido Ostkamp wrote:
>
>> $ mkdir test
>> $ cd test
>> $ git init
>> Initialized empty Git repository in .git/
>> $ git branch experimental
>> fatal: Not a valid object name: 'master'.
>>
>> So, it seems it is not possible to create a named branch on an empty
>> repository.
>
> Actually, it is not possible to branch from a non-existing branch. So,
> this is somewhat expected from my POV.
>From a git beginners point of view, I would expect that the 'master'
branch is automatically created when performing the 'git init'. Why is
this not the case?
Regards
Guido
^ permalink raw reply
* Re: 'upstream' branches.
From: Alex Riesen @ 2007-05-05 17:44 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1178368166.11851.60.camel@pmac.infradead.org>
David Woodhouse, Sat, May 05, 2007 14:29:26 +0200:
> [remote "origin"]
> url = ssh://git.infradead.org/~/public_git/foo-2.6.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> fetch = +refs/heads/mtd:refs/heads/mtd
> fetch = +refs/heads/linus:refs/heads/linus
These pluses request overwriting of the local reference even if it has
more commits than the remote ("is newer"). Are you sure you want that?
> What I have at the moment isn't ideal because I think pulling from the
> 'mtd' tree will fail if the 'linus' branch there is older than the local
> clone's 'linus' branch. But it mostly works.
>
> Is there a better way?
I would just remove the pluses. git-fetch will say that the branch is
already up-to-date, if the local branch already has everything the
remote has.
^ permalink raw reply
* [PATCH] Make --color available to git-status
From: Matthieu Moy @ 2007-05-05 17:37 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
Git has a nice colored output for status, using
$ git runstatus --color
However, this --color is not made available to git-status itself. In
my understanding, runstatus is plumbing, while status is porcelain,
which the average user wants to use.
This patch makes --color available to git-status itself, and documents
it.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-commit.txt | 4 ++++
Documentation/git-status.txt | 5 ++++-
git-commit.sh | 10 ++++++++--
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 53a7bb0..2895225 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -118,6 +118,10 @@ but can be used to amend a merge commit.
-q|--quiet::
Suppress commit summary message.
+--color::
+ Ignored by git-commit, but present for compatibility with
+ gitlink:git-status[1]. Show colored output for git-status.
+
\--::
Do not interpret any more arguments as options.
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index e9e193f..1d6a240 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -23,9 +23,12 @@ If there is no path that is different between the index file and
the current HEAD commit, the command exits with non-zero
status.
+
+OPTIONS
+-------
The command takes the same set of options as `git-commit`; it
shows what would be committed if the same options are given to
-`git-commit`.
+`git-commit`. If --color is used, show a colored output.
OUTPUT
diff --git a/git-commit.sh b/git-commit.sh
index f28fc24..47f006f 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2006 Junio C Hamano
-USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [[-i | -o] <path>...]'
+USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [--color] [[-i | -o] <path>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
require_work_tree
@@ -50,7 +50,7 @@ run_status () {
fi
case "$status_only" in
- t) color= ;;
+ t) ;;
*) color=--nocolor ;;
esac
git-runstatus ${color} \
@@ -87,6 +87,8 @@ signoff=
force_author=
only_include_assumed=
untracked_files=
+color=
+
while case "$#" in 0) break;; esac
do
case "$1" in
@@ -262,6 +264,10 @@ $1"
untracked_files=t
shift
;;
+ --c|--co|--col|--colo|--color)
+ color=--color
+ shift
+ ;;
--)
shift
break
--
1.5.1.3
^ permalink raw reply related
* Re: [RFC PATCH] Rename "bury" back to "sink".
From: Chris Shoemaker @ 2007-05-05 17:35 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, Catalin Marinas, git
In-Reply-To: <20070505131352.GB3379@diana.vm.bytemark.co.uk>
On Sat, May 05, 2007 at 03:13:53PM +0200, Karl Hasselström wrote:
> On 2007-05-05 00:53:03 +0200, Yann Dirson wrote:
>
> > Well, it looks like the voices we heard on this naming issue were
> > quite equally cast towards each of the 2 name.
> >
> > Let my vote be to get back to "sink", so the user can easily pair
> > the command with "float". I expect that any previously-silent
> > majoity prefering "bury" will talk now, before Catalin decides if he
> > wants this patch in the next release :)
>
> Well, my vote is still for "sink"! If it is to be called "stg bury",
> I'd have to vote for changing "stg float" to "stg unearth". :-)
Just my 2.5 cents:
float/sink are clearly related, while I wouldn't associate float/bury
at all. Also, "bury" is sometimes euphemistic for "kill", so
bury/resurrect is a clear pair. Anyway, "sink" makes perfect sense to
me.
-chris
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Linus Torvalds @ 2007-05-05 17:26 UTC (permalink / raw)
To: Karl Hasselstr?m, Paul Mackerras, Junio C Hamano
Cc: Carl Worth, Michael Niedermayer, Git Mailing List
In-Reply-To: <20070505133543.GC3379@diana.vm.bytemark.co.uk>
On Sat, 5 May 2007, Karl Hasselstr?m wrote:
>
> On 2007-05-04 11:17:05 -0700, Carl Worth wrote:
> > or by content of the patches themselves:
> >
> > git log -p -S'snippet of interest'
>
> Somewhat unrelated: how can I make gitk display these (and only these)
> commits? git-log is not bad, but in 95% of cases I find gitk easier to
> use.
>
> I know that I can ask it to highlight commits that insert or remove
> "snippet of interest", but frequently the highlighted commits are ten
> out of ten thousand, and not that easy to find even when boldfaced.
> What I want is to make it display only those commits.
The "-S" thing doesn't really interact well with "gitk", because it
doesn't rewrite the parent information (it is basically just a "hide
commits that don't pass this criteria"). As such, gitk, which requires
parent information to generate the graph, is not very amenable to using
"-S" and such.
That said, you can apply this fairly trivial patch to "gitk" to make it
parse the output of "git log" rather than "git rev-list", and that will
actually get you working -S'xyz' parsing automatically. It's just that the
commit history window will look like crap.
This patch may be worth applying regardless, since there is really no real
reason to use "git rev-list". In fact, I really like the ability to say
gitk --stat
and have the diffstat output visible in the commit window automatically ;)
We might want to teach people that "git rev-list" isn't really all that
useful any more, at least with the fancy stuff (it's still useful for just
generating a list of objects, and for doing things like
git rev-list v2.6.21.. | wc -l
just to count commits).
Junio, Paul?
Linus
---
gitk | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index b1c65d7..bec7bb9 100755
--- a/gitk
+++ b/gitk
@@ -33,8 +33,8 @@ proc start_rev_list {view} {
set order "--date-order"
}
if {[catch {
- set fd [open [concat | git rev-list --header $order \
- --parents --boundary --default HEAD $args] r]
+ set fd [open [concat | git log -z --pretty=raw $order \
+ --parents --boundary $args] r]
} err]} {
puts stderr "Error executing git rev-list: $err"
exit 1
@@ -129,7 +129,8 @@ proc getcommitlines {fd view} {
set ok 0
set listed 1
if {$j >= 0} {
- set ids [string range $cmit 0 [expr {$j - 1}]]
+ # start with 'commit '
+ set ids [string range $cmit 6 [expr {$j - 1}]]
if {[string range $ids 0 0] == "-"} {
set listed 0
set ids [string range $ids 1 end]
@@ -147,7 +148,7 @@ proc getcommitlines {fd view} {
if {[string length $shortcmit] > 80} {
set shortcmit "[string range $shortcmit 0 80]..."
}
- error_popup "Can't parse git rev-list output: {$shortcmit}"
+ error_popup "Can't parse git git log output: {$shortcmit}"
exit 1
}
set id [lindex $ids 0]
^ permalink raw reply related
* Re: [git-svn PATCH] Fix markup in git-svn man page
From: Karl Hasselström @ 2007-05-05 13:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <7vslacs0p6.fsf@assigned-by-dhcp.cox.net>
On 2007-05-04 15:06:45 -0700, Junio C Hamano wrote:
> Looks sane to me. I did not know about double-semicolon, which is
> mentioned in the user guide documentation at the asciidoc site but I
> could not tell how it is different from double-colon form. I am
> guessing (from the behaviour after applying your patch) that it
> allows second level of listing...
Yes, it was used that way in the parts of the man page that already
looked OK, so I just copied it. If it looks good to you too, it must
be correct. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC PATCH] Rename "bury" back to "sink".
From: Karl Hasselström @ 2007-05-05 13:13 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, git
In-Reply-To: <20070504224639.26133.6157.stgit@gandelf.nowhere.earth>
On 2007-05-05 00:53:03 +0200, Yann Dirson wrote:
> Well, it looks like the voices we heard on this naming issue were
> quite equally cast towards each of the 2 name.
>
> Let my vote be to get back to "sink", so the user can easily pair
> the command with "float". I expect that any previously-silent
> majoity prefering "bury" will talk now, before Catalin decides if he
> wants this patch in the next release :)
Well, my vote is still for "sink"! If it is to be called "stg bury",
I'd have to vote for changing "stg float" to "stg unearth". :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Git branch bug
From: Daniel Barkalow @ 2007-05-05 17:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Guido Ostkamp, git
In-Reply-To: <Pine.LNX.4.64.0705051841200.4015@racer.site>
On Sat, 5 May 2007, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 5 May 2007, Guido Ostkamp wrote:
>
> > $ mkdir test
> > $ cd test
> > $ git init
> > Initialized empty Git repository in .git/
> > $ git branch experimental
> > fatal: Not a valid object name: 'master'.
> >
> > So, it seems it is not possible to create a named branch on an empty
> > repository.
>
> Actually, it is not possible to branch from a non-existing branch. So,
> this is somewhat expected from my POV.
This leaves open the question of how you make your initial commit in a
branch that isn't master. I think the answer should be:
$ git checkout -b experimental
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of HEAD.
fatal: just how do you expect me to merge 0 trees?
Which should probably be:
$ git checkout -b experimental
warning: You appear to be on a branch yet to be born.
warning: Putting you on a new branch yet to be born.
And leaving .git/HEAD pointing to refs/heads/experimental instead of
refs/heads/master, with refs/heads/ still empty.
$ git branch experimental
Should probably give a more informative error message, but branches with
no commits that aren't the current branch has no existance at all, so it
can't work to create them without switching to them.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Documentation: "bisect run" can be given bangs before the run script.
From: Christian Couder @ 2007-05-05 12:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, git
In-Reply-To: <7vmz0m3261.fsf@assigned-by-dhcp.cox.net>
Hi Junio and Uwe,
Le jeudi 3 mai 2007 07:29, Junio C Hamano a écrit :
> I am not convinced that '!' is a good extension for two and half
> reasons.
>
> * The expected use is not quite clear. If it is not used to
> run a custom test script but something stock as "make", by
> the nature of UNIX exit status convention, you are looking
> for the commit that _fixed_ some breakage (i.e. "which commit
> fixed the compilation error?"). While sometimes that is a
> useful thing to do, it feels somewhat of limited value.
Well, of course the main expected use is for something like "make" or "grep"
or "./test_something.sh" where "test_something.sh" is an already existing
script.
Especially because "git bisect run ! grep foo bar.txt" seems to me like a
nice way to find the commit that introduced "foo" in "bar.txt" and I have
been frustrated that it does not work. (Perhaps "git blame" can do it too,
but I think "git bisect run" should be faster and more specific.)
> On the other hand, if you are running a custom test script, I
> do not think it is unreasonable to always require that a test
> script to signal "bad" with small non-zero, "good" with zero,
> and error with high non-zero status, as we already do.
I agree this is probably the most usefull use of "git bisect run". But
sometimes, perhaps for a one shot use, you already have something that
could work if only you could revert the exist status. I think it is a good
idea to give user some rope for this case.
> * How should this interact with the "high non-zero status means
> an error and we cannot bisect" return convention?
If you use a bare "! grep foobar /*/*" on the command line for example and
you kill it before it's finished, you will still get a 0 exit code. This
means that, with the bash "!" keyword, any error gives a "good" result. I
think it's better to keep this behavior.
If we still wants something that keeps the "high non-zero status means an
error and we cannot bisect" return convention, then let's call it a "--not"
option or something like that. I will implement that if you prefer. I can
even implement both "!" and "--not" if you want.
By the way I think that sometimes it could happens that any exit code other
than 0 means a "bad" revision and not "we cannot bisect". In this case
using "git bisect run ! ! my_script" can be usefull.
> * I was hoping that we can officially support "don't know,
> cannot test this one, please give me another" for interactive
> use, and at the same time allow the run-script used by
> "git bisect run" to signal such with a special exit value
> (perhaps "exit 42"). Taken together with the previous point,
> it is not clear how '!' should interact with such an
> enhancement.
My bang patch does not in any way prevents from adding such a "don't know,
cannot test this one, please give me another" improvement. It's just
another option to make "git bisect run" more convenient in some cases.
Christian (a give them rope proponent).
^ permalink raw reply
* Re: Git branch bug
From: Johannes Schindelin @ 2007-05-05 16:42 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705051823300.13988@bianca.dialin.t-online.de>
Hi,
On Sat, 5 May 2007, Guido Ostkamp wrote:
> $ mkdir test
> $ cd test
> $ git init
> Initialized empty Git repository in .git/
> $ git branch experimental
> fatal: Not a valid object name: 'master'.
>
> So, it seems it is not possible to create a named branch on an empty
> repository.
Actually, it is not possible to branch from a non-existing branch. So,
this is somewhat expected from my POV.
Ciao,
Dscho
^ 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