* Re: git refuses to work with gvim
From: Joshua Roys @ 2009-10-12 18:29 UTC (permalink / raw)
To: Matthieu Moy; +Cc: sebastian, git
In-Reply-To: <vpq8wfgg4u1.fsf@bauges.imag.fr>
On 10/12/2009 08:43 AM, Matthieu Moy wrote:
> sebastian@CoLi.Uni-SB.DE writes:
>
>> # git commit something
>> fatal: no commit message? aborting commit.
>> #
>
> The problem is that gvim returns immediately, and lets the window
> opened (try it in a terminal, "gvim foo.txt" returns immediately). Git
> expects the commit message to be written and saved when $EDITOR
> returns.
>
> A quick search for "wait" in the man pages tells me that
>
> GIT_EDITOR='gvim -f' git commit
>
> works.
>
> (BTW, this is in no way specific to Git, 99% applications calling
> $EDITOR will expect the same behavior)
>
Hello,
Also, a :help nofork leads to gui-fork and guioptions, which tells you
that you can add the following to .vimrc (not .gvimrc, see :help go-f):
set guioptions+=f
--
Joshua Roys
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Alex Riesen @ 2009-10-12 18:30 UTC (permalink / raw)
To: sylvain; +Cc: Steven Noonan, git
In-Reply-To: <20091012142017.vrs4v2cc8wgws8g4@webmail.demarque.qc.ca>
On Mon, Oct 12, 2009 at 20:20, <sylvain@demarque.qc.ca> wrote:
> Quoting Alex Riesen <raa.lkml@gmail.com>:
>> It's more of "a note to the future generation of developers": "Hey guys,
>> we didn't need that working, but if you have a night to spare could you
>> please finish that?"
>
> Ok, then I won't wait for it to work. I will dive in Git's code and play the
> "future generation of developers" part... some day. ;-)
>
> Thank you! :-)
>
Hmm... This strategy to encourage new contributors didn't quite worked out.
Must try something else next time. Do you like sweets? Just asking...
^ permalink raw reply
* Re: backup git repo on every commit
From: Christian Himpel @ 2009-10-12 18:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Israel Garcia, git
In-Reply-To: <20091012141544.GF9261@spearce.org>
On Mon, Oct 12, 2009 at 07:15:44AM -0700, Shawn O. Pearce wrote:
> Israel Garcia <igalvarez@gmail.com> wrote:
> git remote add --mirror backup you@another.host:path/to/backup.git
>
> cat >.git/hooks/post-commit
> #!/bin/sh
> git push backup
> ^D
>
> chmod a+x .git/hooks/post-commit
Since this is meant as a backup, is there also a sane way to push the
reflog entries as well? Or is it okay just to copy .git/logs to the
backup repository?
Thanks,
chressie
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Jeff King @ 2009-10-12 18:35 UTC (permalink / raw)
To: sylvain; +Cc: Alex Riesen, Steven Noonan, git
In-Reply-To: <20091012142017.vrs4v2cc8wgws8g4@webmail.demarque.qc.ca>
On Mon, Oct 12, 2009 at 02:20:17PM -0400, sylvain@demarque.qc.ca wrote:
> >It's more of "a note to the future generation of developers": "Hey guys,
> >we didn't need that working, but if you have a night to spare could you
> >please finish that?"
>
> Ok, then I won't wait for it to work. I will dive in Git's code and
> play the "future generation of developers" part... some day. ;-)
>
> Thank you! :-)
I think that it sort of works, actually. It seems to do OK if you do
something like:
$ GIT_DIR=/path/to/store/repo; export GIT_DIR
$ GIT_WORK_TREE=/; export GIT_WORK_TREE
$ git init
$ cd /etc/whatever
$ git add .
But it does not work if you try to make things work automatically:
$ cd /
$ git init
$ cd /etc/whatever
$ git add .
So probably the bug is in detecting the location of the work tree when
it is not explicitly given. You can use the explicit style as a
workaround for now.
-Peff
^ permalink raw reply
* Re: Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Björn Steinbrink @ 2009-10-12 18:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Euguess, Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian,
git
In-Reply-To: <alpine.DEB.1.00.0910120941150.4985@pacific.mpi-cbg.de>
On 2009.10.12 09:49:50 +0200, Johannes Schindelin wrote:
> On Tue, 6 Oct 2009, Euguess@gmail.com wrote:
> > I'ma new user of git and I don't think i will ever have a commit in
> > git.git, because I'm not a programmer (I'm QA).
[...]
> > As for the solution i would choose the "simplest thing that will work" -
> > so i think that we just have to notify user about his suicide attempt to
> > checkout nonlocal branch and offer him a correct syntax to go with.
> >
> > Something like below should work:
> >
> > % git clone git://git.git git
> > % git checkout next
> > You're attempting to checkout to non-local branch. This will lead to your HEAD
> > being detached (our team is on its way!).
> > Do you want to check out local branch 'next' tracking 'origin/next' instead?
> > y/n
> >
> > if yes, then:
> > Created branch "next" tracking "origin/next"
> > You can update it with 'git pull'.
> >
> > If no - abort or continue with checkout to nonlocal branch? ('m not sure if
> > detaching HEAD can provide some benefits if done on purpose)
> >
> > I hope I'm not missing anything...
>
> No, I think that is something perfectly fine to expect in a software whose
> UI complexity is unfortunately pretty much in disagreement with its
> internal complexity.
>
> One thing one might add for the technically inclined folks (i.e. those who
> need to implement, and to see that Git is in dear need of some
> user-friendliness first): "git checkout" is a porcelain (i.e. a program
> meant for end-user consumption), and as such should not have a problem to
> react to isatty(0) (i.e. "is the input coming directly from the
> console?").
So I didn't mean to chime in, but anyway... A few days ago, uau on #git
said that he thinks that "git clone" shouldn't create any branch heads
at all. Instead, git should learn to do something like "svn up", when
the user checked out a remote tracking branch. That was specifically
meant for users that _don't_ commit, like, say, QA guys ;-)
I didn't quite agree on the idea (feel free to tell me that I just blank
out UI problems :-p), but anyway, I felt like coming up with some hack
that achieves said functionality. The result was inspired by "git
checkout -" and looks at HEAD's reflog to figure out whether the user
has checked out a remote tracking branch the last time he used checkout
to switch branches. I dared to call it "git-up" in my $HOME/bin ;-)
#!/bin/bash
MODE=${1:---merge}
RTB=$(git rev-parse --symbolic-full-name $(git reflog | grep 'checkout: moving from .* to' | head -1 | sed -e 's/.* to //'))
if [ ${RTB:0:13} != "refs/remotes/" ]
then
echo "You're not on a remote tracking branch"
exit 1
fi
SRTB=${RTB#refs/remotes/}
REMOTE=${SRTB%/*}
git fetch $REMOTE
git reset $MODE $RTB
It's obviously basically just "git reset" on crack, happily dropping
local commits. A "real" implementation would likely have to have more
checks to ensure that the user is using it in an expected way (like
checking that refs/remotes/whatever..HEAD is empty). And it could be
made to work with regular branch heads as well then, as a "fast-forward
only" way of updating (think "git merge --ff-only", but in a less
illogical way, as "--ff-only" actually means "don't create a merge",
which is kinda weird, at least to me).
As I said, I don't really agree on the idea of not creating any branch
heads on "clone", but maybe it's because I'm not a "don't commit, just
watch" person. And the theoretical "git up" command might be handy for
guys that just want to follow things, and thus don't really need branch
heads. At the moment, I don't have any intentions to improve the hack
(also due to lack of time), but if it seems worthwhile to anyone, feel
free to pick it up.
Björn, -ENOPATCH ;-)
^ permalink raw reply
* Re: backup git repo on every commit
From: Shawn O. Pearce @ 2009-10-12 18:37 UTC (permalink / raw)
To: Christian Himpel; +Cc: Israel Garcia, git
In-Reply-To: <20091012183504.GA3872@mrslave>
Christian Himpel <chressie@googlemail.com> wrote:
> Since this is meant as a backup, is there also a sane way to push the
> reflog entries as well? Or is it okay just to copy .git/logs to the
> backup repository?
There isn't a way to transfer reflogs, but one could rsync them
over to the backup. Some records might be missing their SHA-1 in
the backup if that particular object wasn't pushed there, but the
reflog code is generally tolerant of those garbage records.
--
Shawn.
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Matthieu Moy @ 2009-10-12 19:02 UTC (permalink / raw)
To: sylvain; +Cc: git
In-Reply-To: <20091012012826.7sffggwmm8sk0cc8@webmail.demarque.qc.ca>
sylvain@demarque.qc.ca writes:
> localhost / # cd etc
> localhost etc # git add X11/xorg.conf
> fatal: pathspec 'etc/X11/xorg.conf' did not match any files
cd ..
git add etc/X11/xorg.conf
works. I don't know why the other doesn't (just tested adding from an
untracked directory in another project, it does work).
If you want to version a large directory like /, I'd advise putting
"*" in /.gitignore to make sure Git never tries to traverse the whole
filesystem.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Questions about the new
From: Dmitry Potapov @ 2009-10-12 19:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sergio, git
In-Reply-To: <4AD31EBF.6090307@viscovery.net>
On Mon, Oct 12, 2009 at 02:19:11PM +0200, Johannes Sixt wrote:
>
> With grafts you can only change parenthood; with replace entries you can
> change parenthood *and* all other aspects of a commit (message, author,
> committer, dates).
Actually, you can. I have written a script that did exactly this. It
required to modify parents to point to the new commit. The tricky part
was that modification could be on top of other modifications, but I was
able to handle this case too. Yet, my script was so hackish that I have
never dared to share it with someone (and I used it only couple times
during CVS to Git conversion).
>
> Hence, replace entries are more general than grafts.
I think both mechanism are theoretically equivalent, but with grafts,
it was rather difficult to replace objects (but not impossible!).
> The problem with grafts was that, for example, git-pack-objects obeyed the
> graft, and could create a broken repository by removing grafted-away
> objects. And since git-fsck also obeyed the graft, it did not notice the
> breakage.
Moreover, grafted-away objects could be removed by the garbage collector...
Dmitry
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 19:08 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, Steven Noonan, git
In-Reply-To: <20091012183519.GA10686@coredump.intra.peff.net>
Quoting Jeff King <peff@peff.net>:
> On Mon, Oct 12, 2009 at 02:20:17PM -0400, sylvain@demarque.qc.ca wrote:
>
> I think that it sort of works, actually. It seems to do OK if you do
> something like:
>
> $ GIT_DIR=/path/to/store/repo; export GIT_DIR
> $ GIT_WORK_TREE=/; export GIT_WORK_TREE
> $ git init
> $ cd /etc/whatever
> $ git add .
>
> So probably the bug is in detecting the location of the work tree when
> it is not explicitly given. You can use the explicit style as a
> workaround for now.
>
> -Peff
Thank you! Great idea!
export GIT_DIR=/root/.git
export GIT_WORK_TREE=/
echo "*" >> /root/.git/info/exclude
The Golden Solution of the Gods! :-D
^ permalink raw reply
* Re: Supressing sorting of trees
From: Martin Langhoff @ 2009-10-12 19:36 UTC (permalink / raw)
To: Sal Mangano; +Cc: git
In-Reply-To: <loom.20091012T182258-9@post.gmane.org>
On Mon, Oct 12, 2009 at 6:51 PM, Sal Mangano
<smangano@into-technology.com> wrote:
> 2) I can use Git unchanged but preserve order by storing some information in
> each sub tree (e.g. an extra blob) which retains the real order. I can also
This #2 is your best bet by far. An extra blob in each subdir is just
one option, you can handle this "extra metadata" in a number of ways
-- maybe external to git, on a separate history will work best.
The downsides of messing with internal tree handling of git are so
staggering that you'd do better to throw git away.
(this is from experience of abusing git to various purposes that have
little to do with version control :-) )
In other words: Shaun and Dscho are right, so right that it hurts.
hth,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* [PATCH] git-stash documentation: mention default options for 'list'
From: Miklos Vajna @ 2009-10-12 19:37 UTC (permalink / raw)
To: Jeff King; +Cc: Jef Driesen, git
In-Reply-To: <20091012175201.GA10263@coredump.intra.peff.net>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
I just noticed this was not mentioned in the manpage.
Documentation/git-stash.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 3f14b72..fafe728 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -78,7 +78,8 @@ stash@{1}: On master: 9cc0589... Add git-stash
----------------------------------------------------------------
+
The command takes options applicable to the 'git-log'
-command to control what is shown and how. See linkgit:git-log[1].
+command to control what is shown and how. If no options are set, the
+default is `-n 10`. See linkgit:git-log[1].
show [<stash>]::
--
1.6.4
^ permalink raw reply related
* Re: [PATCH] git-stash documentation: mention default options for 'list'
From: Jeff King @ 2009-10-12 19:39 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jef Driesen, git
In-Reply-To: <20091012193739.GR23777@genesis.frugalware.org>
On Mon, Oct 12, 2009 at 09:37:39PM +0200, Miklos Vajna wrote:
> I just noticed this was not mentioned in the manpage.
Thanks, looks like an improvement to me.
-Peff
^ permalink raw reply
* Re: quote in help code example
From: Miklos Vajna @ 2009-10-12 19:40 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091012102926.GA3937@debian.b2j>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
On Mon, Oct 12, 2009 at 06:29:26PM +0800, bill lam <cbill.lam@gmail.com> wrote:
> In git man, eg. git help filter-branch
> The code examples for command line or shell scripts inside .ft pairs
> use (smart?) quote instead of single quotes, like
>
> .ft C
> git filter-branch --tree-filter ´rm filename´ HEAD
> .ft
>
> Is this intentional or just some configuration problem during
> compiling.
Just a guess: do you have docbook-xsl >=1.73.0 and you did not set
ASCIIDOC_NO_ROFF?
Try rebuilding the documentation using 'make ASCIIDOC_NO_ROFF=YesPlease'.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Let --decorate show HEAD position
From: Thomas Rast @ 2009-10-12 20:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, René Scharfe
In-Reply-To: <4c70c935ab67266684aa14e38e276795cf1776db.1255337211.git.trast@student.ethz.ch>
Thomas Rast wrote:
> diff --git a/log-tree.c b/log-tree.c
> index 1618f3c..f7d54f2 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -43,6 +43,7 @@ void load_ref_decorations(int flags)
> if (!loaded) {
> loaded = 1;
> for_each_ref(add_ref_decoration, &flags);
> + head_ref(add_ref_decoration, &flags);
> }
> }
Damn, this fails tests and I only just noticed while testing another
series. Sorry for the noise, reroll upcoming...
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Supressing sorting of trees
From: Salvatore Mangano @ 2009-10-12 20:02 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90910121236x6bbe258bwa3bc3fdcc54de524@mail.gmail.com>
On Oct 12, 2009, at 3:36 PM, Martin Langhoff wrote:
> On Mon, Oct 12, 2009 at 6:51 PM, Sal Mangano
> <smangano@into-technology.com> wrote:
>> 2) I can use Git unchanged but preserve order by storing some
>> information in
>> each sub tree (e.g. an extra blob) which retains the real order. I
>> can also
>
> This #2 is your best bet by far. An extra blob in each subdir is just
> one option, you can handle this "extra metadata" in a number of ways
> -- maybe external to git, on a separate history will work best.
>
> The downsides of messing with internal tree handling of git are so
> staggering that you'd do better to throw git away.
>
> (this is from experience of abusing git to various purposes that have
> little to do with version control :-) )
>
> In other words: Shaun and Dscho are right, so right that it hurts.
>
Thanks Martin. I suspect you, Shaun and Dscho are correct. But, can
anyone point to specific code
that would allow me to see first hand that this is hopeless. So far,
based on the code I looked at, I see
it as problematic but not hopeless. Here I define "problematic" as
having to change a few files and/or
avoid using some features while "hopeless" meaning I'd have to change
almost very single plumbing
command.
^ permalink raw reply
* Re: Supressing sorting of trees
From: Martin Langhoff @ 2009-10-12 20:24 UTC (permalink / raw)
To: Salvatore Mangano; +Cc: git
In-Reply-To: <DF65B4B0-62B1-4469-99E1-3305434F9D59@into-technology.com>
On Mon, Oct 12, 2009 at 10:02 PM, Salvatore Mangano
<smangano@into-technology.com> wrote:
> point to specific code
Shaun pointed out some very core code. And it is just a core concept.
Just read up on the core organizing concept that is the "tree". Git
relies on the layout of the tree being strictly deterministic.
It is a prevalent assumption in the whole codebase.
Yes you can change it, but assume you will have to audit/rewrite 80%
of the core code.
Want "proof"? Go change it, then try "make test", or reimport a large
repository try to use the git commands over it. We'll relax and watch
the fireworks :-)
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* [PATCH v2] Let --decorate show HEAD position
From: Thomas Rast @ 2009-10-12 20:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, René Scharfe
In-Reply-To: <200910122206.23044.trast@student.ethz.ch>
'git log --graph --oneline --decorate --all' is a useful way to get a
general overview of the repository state, similar to 'gitk --all'.
Let it indicate the position of HEAD by loading that ref too, so that
the --decorate code can see it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I wrote:
> Damn, this fails tests and I only just noticed while testing another
> series. Sorry for the noise, reroll upcoming...
log-tree.c | 1 +
t/t4013/diff.log_--decorate=full_--all | 2 +-
t/t4013/diff.log_--decorate_--all | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 1618f3c..f7d54f2 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -43,6 +43,7 @@ void load_ref_decorations(int flags)
if (!loaded) {
loaded = 1;
for_each_ref(add_ref_decoration, &flags);
+ head_ref(add_ref_decoration, &flags);
}
}
diff --git a/t/t4013/diff.log_--decorate=full_--all b/t/t4013/diff.log_--decorate=full_--all
index 903d9d9..d155e0b 100644
--- a/t/t4013/diff.log_--decorate=full_--all
+++ b/t/t4013/diff.log_--decorate=full_--all
@@ -1,5 +1,5 @@
$ git log --decorate=full --all
-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (refs/heads/master)
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, refs/heads/master)
Merge: 9a6d494 c7a2ab9
Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:04:00 2006 +0000
diff --git a/t/t4013/diff.log_--decorate_--all b/t/t4013/diff.log_--decorate_--all
index 954210e..fd7c3e6 100644
--- a/t/t4013/diff.log_--decorate_--all
+++ b/t/t4013/diff.log_--decorate_--all
@@ -1,5 +1,5 @@
$ git log --decorate --all
-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (master)
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, master)
Merge: 9a6d494 c7a2ab9
Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:04:00 2006 +0000
--
1.6.5.62.g4370d.dirty
^ permalink raw reply related
* [PATCH] git: add --no-replace-objects option to disable replacing
From: Christian Couder @ 2009-10-12 20:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jakub Narebski, Johannes Sixt, bill lam, Andreas Schwab
Commit dae556b (environment: add global variable to disable replacement)
adds a variable to enable/disable replacement, and it is enabled by
default for most commands.
So there is no way to disable it for some commands, which is annoying
when we want to get information about a commit that has been replaced.
For example:
$ git cat-file -p N
would output information about the replacement commit if commit N is
replaced.
With the "--no-replace-objects" option that this patch adds it is
possible to get information about the original commit using:
$ git --no-replace-objects cat-file -p N
While at it, let's add some documentation about this new option in the
"git replace" man page too.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replace.txt | 21 +++++++++++++++++++++
Documentation/git.txt | 6 +++++-
git.c | 4 +++-
t/t6050-replace.sh | 7 +++++++
4 files changed, 36 insertions(+), 2 deletions(-)
Here is a patch with some tests and documentation.
The new option is now called "--no-replace-objects" instead of
"--no-replace".
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 915cb77..8adc1ef 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -23,6 +23,26 @@ replacement object.
Unless `-f` is given, the replace reference must not yet exist in
`.git/refs/replace/` directory.
+Replace references will be used by default by all git commands except
+those doing reachability traversal (prune, pack transfer and fsck).
+
+It is possible to disable use of replacement refs for any command
+using the --no-replace-objects option just after "git".
+
+For example if commit "foo" has been replaced by commit "bar":
+
+------------------------------------------------
+$ git --no-replace-object cat-file commit foo
+------------------------------------------------
+
+show information about commit "foo", while:
+
+------------------------------------------------
+$ git cat-file commit foo
+------------------------------------------------
+
+show information about commit "bar".
+
OPTIONS
-------
-f::
@@ -54,6 +74,7 @@ SEE ALSO
--------
linkgit:git-tag[1]
linkgit:git-branch[1]
+linkgit:git[1]
Author
------
diff --git a/Documentation/git.txt b/Documentation/git.txt
index d97aaf5..2f45417 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]
- [-p|--paginate|--no-pager]
+ [-p|--paginate|--no-pager] [--no-replace-objects]
[--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
[--help] COMMAND [ARGS]
@@ -237,6 +237,10 @@ help ...`.
environment is not set, it is set to the current working
directory.
+--no-replace-objects::
+ Do not use replacement refs to replace git objects. See
+ linkgit:git-replace[1] for more information.
+
FURTHER DOCUMENTATION
---------------------
diff --git a/git.c b/git.c
index 9883009..80ebb04 100644
--- a/git.c
+++ b/git.c
@@ -6,7 +6,7 @@
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]\n"
- " [-p|--paginate|--no-pager]\n"
+ " [-p|--paginate|--no-pager] [--no-replace_objects]\n"
" [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]\n"
" [--help] COMMAND [ARGS]";
@@ -87,6 +87,8 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
use_pager = 0;
if (envchanged)
*envchanged = 1;
+ } else if (!strcmp(cmd, "--no-replace-objects")) {
+ read_replace_refs = 0;
} else if (!strcmp(cmd, "--git-dir")) {
if (*argc < 2) {
fprintf(stderr, "No directory given for --git-dir.\n" );
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 8b8bd81..d4818b4 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -70,6 +70,13 @@ test_expect_success 'replace the author' '
git show $HASH2 | grep "O Thor"
'
+test_expect_success 'test --no-replace-objects option' '
+ git cat-file commit $HASH2 | grep "author O Thor" &&
+ git --no-replace-objects cat-file commit $HASH2 | grep "author A U Thor" &&
+ git show $HASH2 | grep "O Thor" &&
+ git --no-replace-objects show $HASH2 | grep "A U Thor"
+'
+
cat >tag.sig <<EOF
object $HASH2
type commit
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: [PATCH v2] Let --decorate show HEAD position
From: Junio C Hamano @ 2009-10-12 21:05 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, René Scharfe
In-Reply-To: <36861d16d0e21c662430882140893ad9a0b2fb25.1255379242.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> 'git log --graph --oneline --decorate --all' is a useful way to get a
> general overview of the repository state, similar to 'gitk --all'.
> Let it indicate the position of HEAD by loading that ref too, so that
> the --decorate code can see it.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
I think this makes sense.
I see HEAD is given at the front in the sample output, which I think also
makes sense. Is it because it is pushed the last? If so, the same commit
at the tip of branch alpha and beta are decorated with beta and then
alpha, I have to wonder...?
>
> I wrote:
>> Damn, this fails tests and I only just noticed while testing another
>> series. Sorry for the noise, reroll upcoming...
>
>
> log-tree.c | 1 +
> t/t4013/diff.log_--decorate=full_--all | 2 +-
> t/t4013/diff.log_--decorate_--all | 2 +-
> 3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/log-tree.c b/log-tree.c
> index 1618f3c..f7d54f2 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -43,6 +43,7 @@ void load_ref_decorations(int flags)
> if (!loaded) {
> loaded = 1;
> for_each_ref(add_ref_decoration, &flags);
> + head_ref(add_ref_decoration, &flags);
> }
> }
>
> diff --git a/t/t4013/diff.log_--decorate=full_--all b/t/t4013/diff.log_--decorate=full_--all
> index 903d9d9..d155e0b 100644
> --- a/t/t4013/diff.log_--decorate=full_--all
> +++ b/t/t4013/diff.log_--decorate=full_--all
> @@ -1,5 +1,5 @@
> $ git log --decorate=full --all
> -commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (refs/heads/master)
> +commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, refs/heads/master)
> Merge: 9a6d494 c7a2ab9
> Author: A U Thor <author@example.com>
> Date: Mon Jun 26 00:04:00 2006 +0000
> diff --git a/t/t4013/diff.log_--decorate_--all b/t/t4013/diff.log_--decorate_--all
> index 954210e..fd7c3e6 100644
> --- a/t/t4013/diff.log_--decorate_--all
> +++ b/t/t4013/diff.log_--decorate_--all
> @@ -1,5 +1,5 @@
> $ git log --decorate --all
> -commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (master)
> +commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, master)
> Merge: 9a6d494 c7a2ab9
> Author: A U Thor <author@example.com>
> Date: Mon Jun 26 00:04:00 2006 +0000
> --
> 1.6.5.62.g4370d.dirty
^ permalink raw reply
* Re: [PATCH/RFC 3/4] git check-ref-format --print
From: Junio C Hamano @ 2009-10-12 21:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jonathan Nieder, Junio C Hamano, Jens Lehmann, git
In-Reply-To: <20091012143922.GL9261@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Jonathan Nieder <jrnieder@gmail.com> wrote:
>> +valid_ref_normalized 'heads/foo' 'heads/foo'
>> +valid_ref_normalized 'refs///heads/foo' 'refs/heads/foo'
>> +invalid_ref_normalized 'foo'
>> +invalid_ref_normalized 'heads/foo/../bar'
>> +invalid_ref_normalized 'heads/./foo'
>> +invalid_ref_normalized 'heads\foo'
>
> What about '/refs/heads/foo'? Shouldn't that drop the leading /?
>
> I actually had someone enter that into Gerrit Code Review once,
> exposing a bug I have yet to fix that permits that as a valid
> branch name. *sigh*
>
> FWIW, I think this is heading in the right direction. Rather
> than teaching the UIs how clean up a name, give us a tool to
> do the normalization and validation, and let us call it when
> we get user input.
I understand that you prefer the latter between "there is no tool; the
caller is responsibile to make sure it feeds us canonical representation"
and "there is a tool that makes a slightly malformed string into canonical
form for the callers to use before calling us." And that would be my
preference between these two as well.
But that is based on the current behaviour of accepting slightly malformed
and silently making it canonical. If we throw a third alternative,
Jonathan's original patch, that did "we reject malformed string", in the
mix, what would be your preference?
I moderately favour the "tool to canonicalize is given, and it would be a
bug for the caller not to use it" approach this series takes primarily
because that approach won't break scripts that do something like this to
make a new branch, optionally grouped by the owner (e.g. 'sp/smart-http'
or 'next'):
owner=$1 topic=$2
branch=$owner/$topic
git branch "$branch"
This currently works as expected as long as it does not later try to
compare for-each-ref output with "refs/heads/$branch" and expects a match.
With the third approach, the optional username grouping becomes mandatory
for such a script, as 'git branch' will error out. To keep the grouping
still optinal, such a script needs to be written perhaps like:
if test -z "$2"
then
branch="$1"
else
branch="$1/$2"
fi
and that would be a hassle for the scripters, but this _could_ be a kind
of backward incompatible tightening we might want to consider for 1.7.0,
as somebody suggested earlier.
But now I have spelled this out, I do not see much upside for rejecting,
and more importantly, I think it would be an independent issue. We can
reject or just keep normalizing silently, and a tool to show the
normalized name would be useful and necessary regardless of that.
^ permalink raw reply
* Re: quote in help code example
From: Junio C Hamano @ 2009-10-12 21:06 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091012102926.GA3937@debian.b2j>
bill lam <cbill.lam@gmail.com> writes:
> In git man, eg. git help filter-branch
> The code examples for command line or shell scripts inside .ft pairs
> use (smart?) quote instead of single quotes, like
>
> .ft C
> git filter-branch --tree-filter ´rm filename´ HEAD
> .ft
>
> Is this intentional or just some configuration problem during
> compiling.
I see these in Documentation/Makefile:
#
# For asciidoc ...
# -7.1.2, no extra settings are needed.
# 8.0-, set ASCIIDOC8.
#
#
# For docbook-xsl ...
# -1.68.1, set ASCIIDOC_NO_ROFF? (based on changelog from 1.73.0)
# 1.69.0, no extra settings are needed?
# 1.69.1-1.71.0, set DOCBOOK_SUPPRESS_SP?
# 1.71.1, no extra settings are needed?
# 1.72.0, set DOCBOOK_XSL_172.
# 1.73.0-, set ASCIIDOC_NO_ROFF
#
#
# If you had been using DOCBOOK_XSL_172 in an attempt to get rid
# of 'the ".ft C" problem' in your generated manpages, and you
# instead ended up with weird characters around callouts, try
# using ASCIIDOC_NO_ROFF instead (it works fine with ASCIIDOC8).
^ permalink raw reply
* Re: Questions about the new
From: Junio C Hamano @ 2009-10-12 21:06 UTC (permalink / raw)
To: Sergio Callegari; +Cc: Johannes Sixt, git
In-Reply-To: <4AD3619C.6010808@gmail.com>
Sergio Callegari <sergio.callegari@gmail.com> writes:
> If I want to replace some commit X by some commit X' I merely need to
> modify the
> parent information of all the commits that are child of X so that they
> pretend
> to be child of X', or am I missing something?
You need to find all the commits that are child of X in the first place.
What should happen if your colleague has such a commit in his repository
(which you haven't fetched from yet), you enumerated all children of X
known to you in your graft file and then you fetch from him? You need to
enumerate all children of X again to keep the graft file up to date.
> Thanks for the explanation. Can this be made possible for grafts too?
> Wouldn't it be a matter of having history walkers never obey grafts but
> keep track of them (i.e. of the history of the parenthood they
> reference)?
In the past we discussed the possibility of that for quite a while but
never saw a successful implementation. The replace mechanism seemed a
cleaner way to do this, and it turned out to be the case.
You are welcome to try doing that for the grafts, of course.
^ permalink raw reply
* [RFC PATCH 1/5] reflog-walk: refactor the branch@{num} formatting
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
We'll use the same output in an upcoming commit, so refactor its
formatting (which was duplicated anyway) into a separate function.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
reflog-walk.c | 56 ++++++++++++++++++++++++++++++++++----------------------
1 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/reflog-walk.c b/reflog-walk.c
index 5623ea6..9478dbc 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -241,36 +241,48 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
commit->object.flags &= ~(ADDED | SEEN | SHOWN);
}
-void show_reflog_message(struct reflog_walk_info *info, int oneline,
+void get_reflog_selector(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info,
+ enum date_mode dmode)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+
+ if (!commit_reflog)
+ return;
+
+ strbuf_addf(sb, "%s@{", commit_reflog->reflogs->ref);
+ if (commit_reflog->flag || dmode) {
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ strbuf_addf(sb, "%s", show_date(info->timestamp,
+ info->tz,
+ dmode));
+ } else {
+ strbuf_addf(sb, "%d", commit_reflog->reflogs->nr
+ - 2 - commit_reflog->recno);
+ }
+
+ strbuf_addch(sb, '}');
+}
+
+void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
- if (info && info->last_commit_reflog) {
- struct commit_reflog *commit_reflog = info->last_commit_reflog;
+ if (reflog_info && reflog_info->last_commit_reflog) {
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
struct reflog_info *info;
+ struct strbuf selector = STRBUF_INIT;
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ get_reflog_selector(&selector, reflog_info, dmode);
if (oneline) {
- printf("%s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || dmode)
- printf("%s", show_date(info->timestamp,
- info->tz,
- dmode));
- else
- printf("%d", commit_reflog->reflogs->nr
- - 2 - commit_reflog->recno);
- printf("}: %s", info->message);
+ printf("%s: %s", selector.buf, info->message);
}
else {
- printf("Reflog: %s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || dmode)
- printf("%s", show_date(info->timestamp,
- info->tz,
- dmode));
- else
- printf("%d", commit_reflog->reflogs->nr
- - 2 - commit_reflog->recno);
- printf("} (%s)\nReflog message: %s",
- info->email, info->message);
+ printf("Reflog: %s (%s)\nReflog message: %s",
+ selector.buf, info->email, info->message);
}
+
+ strbuf_release(&selector);
}
}
--
1.6.5.64.g01287
^ permalink raw reply related
* [RFC PATCH 0/5] Pretty formats for reflog data
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen, Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <20091012175201.GA10263@coredump.intra.peff.net>
[I forgot to address the list on the first batch, sorry for the spam.]
Jeff King wrote:
> On Mon, Oct 12, 2009 at 05:47:34PM +0200, Jef Driesen wrote:
>
> > Is it possible to make "git stash list" show more than 10 items?
>
> Try "git stash list -30".
>
> Stash listing is internally just "git log -g refs/stash", so you can
> pass any formatting or limiting arguments you want there (see the git
> log documentation for ideas). If no arguments are given, we pass "-10".
This seems fairly arbitrary, doesn't it? My own working theory is
that Nanako put it in because the git-log|sed construct inherently
bars any way to a pager, so it needs to be cut short.
So suppose we could somehow get rid of the |sed... like if we had
--pretty specifiers for the reflog information.
Sadly
git log -g --format="%h %g: %G"
still fails to exactly replicate the reflog format: if the reflog was
cut off during garbage collection, the last entry refers to a no
longer existing commit causing a stray ':' on that line. Oh, well.
It's also still RFC because:
* I don't like the massive code churn in 2/5, maybe someone sees a
better option.
* 5/5 has a pretty lame excuse. I could also just change it in 'git
stash list' to limit the backwards-incompatibility damage, but
that's also a maintenance headache.
Thomas Rast (5):
reflog-walk: refactor the branch@{num} formatting
Introduce new pretty formats %g and %G for reflog information
stash: Use new %g/%G formats instead of sed
stash list: drop the default limit of 10 stashes
stash: change built-in ref to 'stash' instead of 'refs/stash'
archive.c | 2 +-
builtin-branch.c | 3 +-
builtin-checkout.c | 2 +-
builtin-commit.c | 4 +-
builtin-log.c | 2 +-
builtin-merge.c | 2 +-
builtin-rev-list.c | 2 +-
builtin-shortlog.c | 2 +-
builtin-show-branch.c | 2 +-
commit.h | 7 +++-
git-stash.sh | 10 +-----
log-tree.c | 4 +-
pretty.c | 20 +++++++++++--
reflog-walk.c | 72 ++++++++++++++++++++++++++++++++++---------------
reflog-walk.h | 7 +++++
15 files changed, 94 insertions(+), 47 deletions(-)
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Junio C Hamano @ 2009-10-12 21:06 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0910121237540.2223@dr-wily.mit.edu>
Anders Kaseorg <andersk@MIT.EDU> writes:
> ‘git bisect reset’ could already checkout an arbitrary commit if you
> were on a detached HEAD before starting the bisection. This lets you
> specify an arbitrary commit to ‘git bisect reset <commit>’.
>
> This also provides a way to clean the bisection state without moving
> HEAD: ‘git bisect reset HEAD’.
>
> Signed-off-by: Anders Kaseorg <andersk@mit.edu>
> ---
> git-bisect.sh | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index 6f6f039..d319b9f 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -311,8 +311,7 @@ bisect_reset() {
> }
> case "$#" in
> 0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
> - 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
> - die "$1 does not seem to be a valid branch"
> + 1) git rev-parse --verify "$1^{commit}" || exit
> branch="$1" ;;
> *)
> usage ;;
Thanks.
The "one parameter" case dates back to the original bisect implementation
in commit 8cc6a08 (Making it easier to find which change introduced a bug,
2005-07-30), and the only reason of existence for that case was that the
code looked like this back then:
bisect_reset() {
case "$#" in
0) branch=master ;;
1) test -f "$GIT_DIR/refs/heads/$1" || {
echo >&2 "$1 does not seem to be a valid branch"
exit 1
}
branch="$1" ;;
*)
usage ;;
esac
...
An important difference to notice, compared to a more recent version, is
that we did not remember (nor use) the original branch, and without an
argument we always switched to 'master'. Back then, the user who started
bisecting a side branch needed to remember the name of the branch before
starting the bisection, and needed to give that to the reset subcommand.
Because we remember where we came from these days, I do not think it makes
much sense to even keep this "one parameter" case, let alone extending
this interface to allow switching to an arbitrary commit.
I even think that the support for an explicit branch name in the reset
subcommand should eventually be deprecated, perhaps unless it matches what
is stored in BISECT_START.
The documentation, does not even talk about what the optional <branch>
argument is good for, even though it lists the optional <branch> in the
synopsis section.
Having said all that, four years and two months are looooooong time in git
timescale, and I am discounting, without any evidence to judge either way,
the possibility that people may have learned during that time to (ab)use
this as a (very useful?) shortcut to finish the current bisection and
switch to some entirely different branch.
I offhand do not see a good rationale for such a shortcut to finish bisect
and switch to another branch (IOW, I understand "it is shorter to type",
but I do not see "it is often done and very useful"), but I am open to be
enlightened by a workflow where such a shortcut is useful.
^ 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