* Re: [PATCH] Add a manual page for git-stash
From: Junio C Hamano @ 2007-06-30 17:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: しらいしななこ, GIT
In-Reply-To: <Pine.LNX.4.64.0706301644190.4438@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> +DESCRIPTION
> +-----------
> +Use 'git stash' when you want to record the current state of the
> +working directory and the index, but want to go back to a clean
> +working directory.
> +
> +For example, if you have to pull, but are in the middle of some
> +interesting work, not yet ready to be committed, use git-stash.
> +
> +The default operation (when called without options), is to save
> +the changes away.
> +
> +
> +OPTIONS
> +-------
> +clear::
> + Undo _all_ stashes (dangerous!).
> +
> +list [<stashname>]::
> + List all stashed states.
> +
I suspect that is not what the implementation intends to do.
"list -n 4", "list --since=1.hour" would make sense, but "list
stash@{12}" would probably not.
> +show [<stashname>]::
> + Show a combined diff of the stashed working directory, index and
> + HEAD.
Is that what it does? I had an impression that "show stash@{2}"
shows a regular diff between the base and the stashed working
tree state.
> +apply [<stashname>]::
> + Try to apply the stashed changes to the current HEAD. You need
> + a clean working directory for that, i.e. you must not have changes
> + relative to HEAD in your working directory or index.
The implementation appears to apply on a clean index without
restriction to where the HEAD is. I hinted that that behaviour
is fine in my previous message, but on the other hand haven't
convinced myself enough to say that it would not confuse end
users. Maybe insisting on not just clean index but no changes
from the HEAD would reduce confusion? I dunno.
> +<stashname>::
> + A name of a stashed state. Typically something like 'stash@{2}'
> + or 'stash@{2.days.ago}'.
Probably this should be defined in DESCRIPTION, along with the
definition of what a stash is ("records the difference between
the HEAD when the stash was created and the working tree state
in such a way that it can be applied to a different state
later").
> +DISCUSSION
> +----------
> +
> +The state is saved as three commits:
> +
> +- HEAD,
> +- a commit which contains the state of the index, which has HEAD as a
> + parent, and
> +- a commit which contains the state of the working directory (only the
> + tracked files, though), which has both HEAD and the second commit
> + as parents.
> +
> +The third commit holds the complete information of the stash, and is
> +stored as the ref 'refs/stash'.
> +
> +Since that commit does not have any reference to other stashed states,
> +the stash listing relies on the reflog of 'refs/stash'. Therefore,
> +the stashed states are garbage collected like all the other reflogs.
Nit; s/the other reflogs/the other reflog entries/
> +Author
> +------
> +Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>
You wrote that ;-)?
^ permalink raw reply
* [PATCH] Add diff-option --ext-diff
From: Johannes Schindelin @ 2007-06-30 17:47 UTC (permalink / raw)
To: git, gitster
To prevent funky games with external diff engines, git-log and
friends prevent external diff engines from being called. That makes
sense in the context of git-format-patch or git-rebase.
However, for "git log -p" it is not so nice to get the message
that binary files cannot be compared, while "git diff" has no
problems with them, if you provided an external diff driver.
With this patch, "git log --ext-diff -p" will do what you expect,
and the option "--no-ext-diff" can be used to override that
setting.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/diff-options.txt | 8 ++++++++
diff.c | 4 ++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 0f07c9c..3d2b9d0 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -168,5 +168,13 @@
--quiet::
Disable all output of the program. Implies --exit-code.
+--ext-diff::
+ Allow an external diff helper to be executed. If you set an
+ external diff driver with gitlink:gitattributes(5), you need
+ to use this option with gitlink:git-log(1) and friends.
+
+--no-ext-diff::
+ Disallow external diff drivers.
+
For more detailed explanation on these common options, see also
link:diffcore.html[diffcore documentation].
diff --git a/diff.c b/diff.c
index e0edb98..a471c9e 100644
--- a/diff.c
+++ b/diff.c
@@ -2241,6 +2241,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
options->exit_with_status = 1;
else if (!strcmp(arg, "--quiet"))
options->quiet = 1;
+ else if (!strcmp(arg, "--ext-diff"))
+ options->allow_external = 1;
+ else if (!strcmp(arg, "--no-ext-diff"))
+ options->allow_external = 0;
else
return 0;
return 1;
--
1.5.2.2.3249.g33841
^ permalink raw reply related
* Re: [PATCH] Add a manual page for git-stash
From: Johannes Schindelin @ 2007-06-30 17:48 UTC (permalink / raw)
To: Frank Lichtenheld
Cc: しらいしななこ, GIT,
Junio C Hamano
In-Reply-To: <20070630163823.GT12721@planck.djpig.de>
Hi,
On Sat, 30 Jun 2007, Frank Lichtenheld wrote:
> On Sat, Jun 30, 2007 at 04:44:39PM +0100, Johannes Schindelin wrote:
> > +Author
> > +------
> > +Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>
>
> AFAICT "Author" is usually used for the author of the documented program
> and "Documentation" for the author of the documentation itself.
Oh? If that is so, please disregard this hunk.
Although in that case, git-bundle.txt is misattributed.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Correct the name of NO_R_TO_GCC_LINKER in the comment describing it.
From: Matt Kraai @ 2007-06-30 17:05 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index a98e27a..5d60dc8 100644
--- a/Makefile
+++ b/Makefile
@@ -94,9 +94,9 @@ all::
# Define OLD_ICONV if your library has an old iconv(), where the second
# (input buffer pointer) parameter is declared with type (const char **).
#
-# Define NO_R_TO_GCC if your gcc does not like "-R/path/lib" that
-# tells runtime paths to dynamic libraries; "-Wl,-rpath=/path/lib"
-# is used instead.
+# Define NO_R_TO_GCC_LINKER if your gcc does not like "-R/path/lib"
+# that tells runtime paths to dynamic libraries;
+# "-Wl,-rpath=/path/lib" is used instead.
#
# Define USE_NSEC below if you want git to care about sub-second file mtimes
# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] Add a manual page for git-stash
From: Johannes Schindelin @ 2007-06-30 17:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ, GIT
In-Reply-To: <7vps3dcp76.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 30 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > +DESCRIPTION
> > +-----------
> > +Use 'git stash' when you want to record the current state of the
> > +working directory and the index, but want to go back to a clean
> > +working directory.
> > +
> > +For example, if you have to pull, but are in the middle of some
> > +interesting work, not yet ready to be committed, use git-stash.
> > +
> > +The default operation (when called without options), is to save
> > +the changes away.
> > +
> > +
> > +OPTIONS
> > +-------
> > +clear::
> > + Undo _all_ stashes (dangerous!).
> > +
> > +list [<stashname>]::
> > + List all stashed states.
> > +
>
> I suspect that is not what the implementation intends to do.
> "list -n 4", "list --since=1.hour" would make sense, but "list
> stash@{12}" would probably not.
Okay, I misunderstood the _intention_ of the code, then.
> > +show [<stashname>]::
> > + Show a combined diff of the stashed working directory, index and
> > + HEAD.
>
> Is that what it does? I had an impression that "show stash@{2}"
> shows a regular diff between the base and the stashed working
> tree state.
Ah, you're completely right! Somehow my tired eyes read what I expected to
find there.
> > +apply [<stashname>]::
> > + Try to apply the stashed changes to the current HEAD. You need
> > + a clean working directory for that, i.e. you must not have changes
> > + relative to HEAD in your working directory or index.
>
> The implementation appears to apply on a clean index without
> restriction to where the HEAD is. I hinted that that behaviour
> is fine in my previous message, but on the other hand haven't
> convinced myself enough to say that it would not confuse end
> users. Maybe insisting on not just clean index but no changes
> from the HEAD would reduce confusion? I dunno.
I am sure confused why the index state is stashed away when it is not
used...
> > +<stashname>::
> > + A name of a stashed state. Typically something like 'stash@{2}'
> > + or 'stash@{2.days.ago}'.
>
> Probably this should be defined in DESCRIPTION, along with the
> definition of what a stash is ("records the difference between
> the HEAD when the stash was created and the working tree state
> in such a way that it can be applied to a different state
> later").
Okay.
> > +DISCUSSION
> > +----------
> > +
> > +The state is saved as three commits:
> > +
> > +- HEAD,
> > +- a commit which contains the state of the index, which has HEAD as a
> > + parent, and
> > +- a commit which contains the state of the working directory (only the
> > + tracked files, though), which has both HEAD and the second commit
> > + as parents.
> > +
> > +The third commit holds the complete information of the stash, and is
> > +stored as the ref 'refs/stash'.
> > +
> > +Since that commit does not have any reference to other stashed states,
> > +the stash listing relies on the reflog of 'refs/stash'. Therefore,
> > +the stashed states are garbage collected like all the other reflogs.
>
> Nit; s/the other reflogs/the other reflog entries/
Okay.
> > +Author
> > +------
> > +Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>
>
> You wrote that ;-)?
No. ;-)
Hey, be nice. It's a new role for me, usually others document what _I_
wrote, not vice versa :-)
Ciao,
Dscho
^ permalink raw reply
* Re: Question about git-prune
From: Johannes Schindelin @ 2007-06-30 18:02 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706300915440.16800@x2.ybpnyarg>
Hi,
On Sat, 30 Jun 2007, walt wrote:
> $cd src/git
> $git-fsck
> dangling tree c642c018aa55d39fff061183f58062de9d8375ac
> dangling commit e1341abc3759950e891822088cb0163b71b316b3
> dangling commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4
> dangling commit b82871b3c32faa8a317007f343fdf2d0ddc9954e
> $git-prune
> $git-fsck
> dangling tree c642c018aa55d39fff061183f58062de9d8375ac
> dangling commit e1341abc3759950e891822088cb0163b71b316b3
> dangling commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4
> dangling commit b82871b3c32faa8a317007f343fdf2d0ddc9954e
Probably the objects were packed.
I do not understand why you use git-prune directly, to begin with. Why not
use git-gc and be done with it?
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a manual page for git-stash
From: Junio C Hamano @ 2007-06-30 18:13 UTC (permalink / raw)
To: Johannes Schindelin
Cc: しらいしななこ, GIT
In-Reply-To: <Pine.LNX.4.64.0706301853400.4438@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > +apply [<stashname>]::
>> > + Try to apply the stashed changes to the current HEAD. You need
>> > + a clean working directory for that, i.e. you must not have changes
>> > + relative to HEAD in your working directory or index.
>>
>> The implementation appears to apply on a clean index without
>> restriction to where the HEAD is. I hinted that that behaviour
>> is fine in my previous message, but on the other hand haven't
>> convinced myself enough to say that it would not confuse end
>> users. Maybe insisting on not just clean index but no changes
>> from the HEAD would reduce confusion? I dunno.
>
> I am sure confused why the index state is stashed away when it is not
> used...
Yeah, I think Nanako kept this from her previous round because I
mentioned that "git show stash" (not "git stash show") is
interesting in that it gives stashed (HEAD, index, working tree)
in --cc fashion. I also mentioned that it might make sense to
stash untracked files in the working tree portion of the commit,
and if we do that then we would need to record what was known to
git by the index tree so that we can discard them from the index
upon applying, but (1) I no longer think it is useful to try
carrying forward the untracked file states, and (2) it would
make "git show stash" uninteresting (too much cruft).
So perhaps we would want to drop the index tree portion from the
stash.
>> > +Author
>> > +------
>> > +Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>
>>
>> You wrote that ;-)?
>
> No. ;-)
>
> Hey, be nice. It's a new role for me, usually others document what _I_
> wrote, not vice versa :-)
Actually I have been wondering if it is a good idea to start
dropping the Author section. Perhaps replace it by list of
stakeholders or people who have been active in the area recently
and who are likely to be able to help when an end-user has
troubles with the command.
^ permalink raw reply
* [PATCH] Makefile: USE_SYMLINK option
From: Matthias Lederhofer @ 2007-06-30 18:14 UTC (permalink / raw)
To: git
When USE_SYMLINK is defined symlinks will be used instead of hardlinks.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
I found no real drawback using symlinks and symlinks are sometimes
more practical, for example when copying/creating a tarball of the
installation.
---
Makefile | 17 +++++++++++++----
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 4ea5e45..db0b818 100644
--- a/Makefile
+++ b/Makefile
@@ -181,6 +181,11 @@ INSTALL = install
RPMBUILD = rpmbuild
TCL_PATH = tclsh
TCLTK_PATH = wish
+ifdef USE_SYMLINK
+LN = ln -s
+else
+LN = ln
+endif
export TCL_PATH TCLTK_PATH
@@ -759,10 +764,10 @@ git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
help.o: common-cmds.h
git-merge-subtree$X: git-merge-recursive$X
- $(QUIET_BUILT_IN)rm -f $@ && ln git-merge-recursive$X $@
+ $(QUIET_BUILT_IN)rm -f $@ && $(LN) git-merge-recursive$X $@
$(BUILT_INS): git$X
- $(QUIET_BUILT_IN)rm -f $@ && ln git$X $@
+ $(QUIET_BUILT_IN)rm -f $@ && $(LN) git$X $@
common-cmds.h: ./generate-cmdlist.sh
@@ -1004,12 +1009,16 @@ ifndef NO_TCLTK
endif
if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
then \
- ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
+ $(LN) -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || \
cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
fi
- $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+ifdef USE_SYMLINK
+ $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && $(LN) 'git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+else
+ $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && $(LN) '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+endif
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
endif
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH] Correct the name of NO_R_TO_GCC_LINKER in the comment describing it.
From: Junio C Hamano @ 2007-06-30 18:16 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <11832231032116-git-send-email-kraai@ftbfs.org>
Thanks.
^ permalink raw reply
* Re: [PATCH] git-merge-ff: fast-forward only merge
From: Matthias Lederhofer @ 2007-06-30 18:32 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <11831937823756-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> This is primarily so that there is an easy switch to 'git-pull' to
> be sure to fast forward only.
Is this still broken or am I just doing something totally wrong?
% git reset --hard origin/master~15
HEAD is now at e1341ab... Merge branch 'master' of git://git.kernel.org/pub/scm/gitk/gitk into pm/gitk
% git merge -s ff origin/master
Automatic merge failed; fix conflicts and then commit the result.
[1] 19368 exit 1 git merge -s ff origin/master
% git merge origin/master
Updating e1341ab..7c85173
Fast forward
[..]
23 files changed, 236 insertions(+), 79 deletions(-)
^ permalink raw reply
* Re: [PATCH] Don't fflush(stdout) when it's not helpful
From: Junio C Hamano @ 2007-06-30 18:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Jeff King, Frank Lichtenheld, Jim Meyering, git
In-Reply-To: <alpine.LFD.0.98.0706292114350.8675@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
>> I was planning to push this out to 'master' this weekend.
>
> I think that code is fine, but switching the order around could probably
> make it less likely that stdio loses the errno for us.
>
> So doing the last part in a different order, and making it say
>
> /* Check for ENOSPC and EIO errors.. */
> if (fflush(stdout))
> die("write failure on standard output: %s", strerror(errno));
> if (ferror(stdout))
> die("unknown write failure on standard output");
> if (fclose(stdout))
> die("close failed on standard output: %s", strerror(errno));
> return 0;
>
> may recover at least non-transient errors.
That makes sense, to a certain degree, given that we do not
check every printf(). I'll forge your signature as usual ;-)
Thanks.
^ permalink raw reply
* Re: [PATCH] Add a manual page for git-stash
From: Johannes Schindelin @ 2007-06-30 18:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ, GIT
In-Reply-To: <7vk5tlcnuq.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 30 Jun 2007, Junio C Hamano wrote:
> So perhaps we would want to drop the index tree portion from the stash.
That was actually the only reason I found it useful to write a script for
it. Otherwise, the revised alias would do just fine.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a manual page for git-stash
From: Frank Lichtenheld @ 2007-06-30 18:45 UTC (permalink / raw)
To: Johannes Schindelin
Cc: しらいしななこ, GIT,
Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706301847370.4438@racer.site>
On Sat, Jun 30, 2007 at 06:48:27PM +0100, Johannes Schindelin wrote:
> On Sat, 30 Jun 2007, Frank Lichtenheld wrote:
> > On Sat, Jun 30, 2007 at 04:44:39PM +0100, Johannes Schindelin wrote:
> > > +Author
> > > +------
> > > +Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>
> >
> > AFAICT "Author" is usually used for the author of the documented program
> > and "Documentation" for the author of the documentation itself.
>
> Oh? If that is so, please disregard this hunk.
Documentation$ grep -B2 -i "\(written\|documentation\) by" *.txt
seems to suggest that I'm right.
> Although in that case, git-bundle.txt is misattributed.
Indeed.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] Makefile: USE_SYMLINK option
From: Junio C Hamano @ 2007-06-30 18:46 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070630181456.GA15035@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> I found no real drawback using symlinks and symlinks are sometimes
> more practical, for example when copying/creating a tarball of the
> installation.
Well, tar handles hard links just fine, thanks. The real
drawbacks of doing symlinks people often cite (and I agree to)
are that they can become dangling, and they consume i-nodes.
^ permalink raw reply
* Start deprecating "git-command" in favor of "git command"
From: Linus Torvalds @ 2007-06-30 18:49 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
I realize that a lot of people use the "git-xyzzy" format, and we have
various historical reasons for it, but I also think that most people have
long since started thinking of the git command as a single command with
various subcommands, and we've long had the documentation talk about it
that way.
Slowly migrating away from the git-xyzzy format would allow us to
eventually no longer install hundreds of binaries (even if most of them
are symlinks or hardlinks) in users $PATH, and the _original_ reasons for
it (implementation issues and bash completion) are really long long gone.
Using "git xyzzy" also has some fundamental advantages, like the ability
to specify things like paging ("git -p xyzzy") and making the whole notion
of aliases act like other git commands (which they already do, but they do
*not* have a "git-xyzzy" form!)
Anyway, while actually removing the "git-xyzzy" things is not practical
right now, we can certainly start slowly to deprecate it internally inside
git itself - in the shell scripts we use, and the test vectors.
This patch adds a "remove-dashes" makefile target, which does that. It
isn't particularly efficient or smart, but it *does* successfully rewrite
a lot of our shell scripts to use the "git xyzzy" form for all built-in
commands.
(For non-builtins, the "git xyzzy" format implies an extra execve(), so
this script leaves those alone).
So apply this patch, and then run
make remove-dashes
make test
git commit -a
to generate a much larger patch that actually starts this transformation.
(The only half-way subtle thing about this is that it also fixes up
git-filter-branch.sh for the new world order by adding quoting around
the use of "git-commit-tree" as an argument. It doesn't need it in that
format, but when changed into "git commit-tree" it is no longer a single
word, and the quoting maintains the old behaviour).
NOTE! This does not yet mean that you can actually stop installing the
"git-xyzzy" binaries for the builtins. There are some remaining places
that want to use the old form, this just removes the most obvious ones
that can easily be done automatically.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
Comments? I think this is worth doing, but the patch that this scripting
generates is actually fairly large, even if this patch itself is smallish.
Junio, up to you.
Makefile | 3 ++-
fixup-builtins | 16 ++++++++++++++++
git-filter-branch.sh | 2 +-
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index a98e27a..1620ef8 100644
--- a/Makefile
+++ b/Makefile
@@ -987,7 +987,8 @@ check-sha1:: test-sha1$X
check: common-cmds.h
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
-
+remove-dashes:
+ ./fixup-builtins $(BUILT_INS)
### Installation rules
diff --git a/fixup-builtins b/fixup-builtins
new file mode 100755
index 0000000..d7fae43
--- /dev/null
+++ b/fixup-builtins
@@ -0,0 +1,16 @@
+#!/bin/sh
+while [ "$1" ]
+do
+ old="$1"
+ new=$(echo "$1" | sed 's/git-/git /')
+ echo "Converting '$old' to '$new'"
+ git ls-files '*.sh' | while read file
+ do
+ sed "s/$old/$new/g" < $file > $file.new
+ chmod --reference=$file $file.new
+ mv $file.new $file
+ done
+ shift
+done
+git update-index --refresh >& /dev/null
+exit 0
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 8fa5ce6..0f54271 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -383,7 +383,7 @@ while read commit parents; do
sed -e '1,/^$/d' <../commit | \
eval "$filter_msg" | \
- sh -c "$filter_commit" git-commit-tree $(git-write-tree) $parentstr | \
+ sh -c "$filter_commit" "git-commit-tree" $(git-write-tree) $parentstr | \
tee ../map/$commit
done <../revs
^ permalink raw reply related
* Re: Start deprecating "git-command" in favor of "git command"
From: Junio C Hamano @ 2007-06-30 19:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706301135300.1172@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Using "git xyzzy" also has some fundamental advantages, like the ability
> to specify things like paging ("git -p xyzzy") and making the whole notion
> of aliases act like other git commands (which they already do, but they do
> *not* have a "git-xyzzy" form!)
In the longer run, we may want to allow "git foo" to alias to
"git foo --preferred-options", although we currently do not
allow such an alias. Scripts, especially the ones we ship,
would not want to be confused by the user aliases when that
happens.
> Anyway, while actually removing the "git-xyzzy" things is not practical
> right now, we can certainly start slowly to deprecate it internally inside
> git itself - in the shell scripts we use, and the test vectors.
So I am somewhat negative on this, unless there is a way for
scripts to say "Even though I say 'git foo', I do mean 'git foo'
not whatever the user has aliased".
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Yann Dirson @ 2007-06-30 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vy7i1b6bt.fsf@assigned-by-dhcp.cox.net>
On Sat, Jun 30, 2007 at 12:17:10PM -0700, Junio C Hamano wrote:
> So I am somewhat negative on this, unless there is a way for
> scripts to say "Even though I say 'git foo', I do mean 'git foo'
> not whatever the user has aliased".
"git --no-alias foo" (like "cvs -f foo" which ignores ~/.cvsrc) ?
Best regards,
--
Yann
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Linus Torvalds @ 2007-06-30 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vy7i1b6bt.fsf@assigned-by-dhcp.cox.net>
On Sat, 30 Jun 2007, Junio C Hamano wrote:
>
> In the longer run, we may want to allow "git foo" to alias to
> "git foo --preferred-options", although we currently do not
> allow such an alias. Scripts, especially the ones we ship,
> would not want to be confused by the user aliases when that
> happens.
I agree. And I think our current behaviour is the correct one.
> So I am somewhat negative on this, unless there is a way for
> scripts to say "Even though I say 'git foo', I do mean 'git foo'
> not whatever the user has aliased".
Well, we have a more serious issue, that is related, but has nothing to do
with aliases.
If you set an environment variable "diff.color=always", any script will
get that behaviour, and not work the way it might expect.
My point being that this has nothing to do with "git-diff" vs "git diff",
and everything to do with default configurations. If you don't want people
to be able to change fixed behaviour, you'd need to have a way to disable
it.
Quite frankly, I think it's _easier_ to disable with "git xyzzy" than with
"git-xyzzy", but hey, not a big deal. With "git xyzzy", we could add a
generic flag like
git - xyzzy
to make the rule be that no configurations (_including_ aliases) are
allowed to override default behaviour, which is much harder with the
"git-xyzzy" format (since then it's invariably a per-command thing).
That said, I'm not going to push that patch very hard.
Especially as I just realized that it had a bug: it caused things like
-our \$logo = "file:///$(pwd)/../../gitweb/git-logo.png";
+our \$logo = "file:///$(pwd)/../../gitweb/git logo.png";
because "git-log" got rewritten as "git log", without checking that it was
a proper word.
I have a fixed version already (just make the sed script use \<..\> around
the pattern - appended here), but as mentioned, I don't think this is a
hugely important issue. I prefer the "git cmd" form, but if we want to
maintain "git-cmd" forever, then hey...
Linus
---
Fixed the sed pattern a bit..
Makefile | 3 ++-
fixup-builtins | 16 ++++++++++++++++
git-filter-branch.sh | 2 +-
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index a98e27a..1620ef8 100644
--- a/Makefile
+++ b/Makefile
@@ -987,7 +987,8 @@ check-sha1:: test-sha1$X
check: common-cmds.h
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
-
+remove-dashes:
+ ./fixup-builtins $(BUILT_INS)
### Installation rules
diff --git a/fixup-builtins b/fixup-builtins
new file mode 100755
index 0000000..49e861d
--- /dev/null
+++ b/fixup-builtins
@@ -0,0 +1,16 @@
+#!/bin/sh
+while [ "$1" ]
+do
+ old="$1"
+ new=$(echo "$1" | sed 's/git-/git /')
+ echo "Converting '$old' to '$new'"
+ git ls-files '*.sh' | while read file
+ do
+ sed "s/\\<$old\\>/$new/g" < $file > $file.new
+ chmod --reference=$file $file.new
+ mv $file.new $file
+ done
+ shift
+done
+git update-index --refresh >& /dev/null
+exit 0
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 8fa5ce6..0f54271 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -383,7 +383,7 @@ while read commit parents; do
sed -e '1,/^$/d' <../commit | \
eval "$filter_msg" | \
- sh -c "$filter_commit" git-commit-tree $(git-write-tree) $parentstr | \
+ sh -c "$filter_commit" "git-commit-tree" $(git-write-tree) $parentstr | \
tee ../map/$commit
done <../revs
^ permalink raw reply related
* Re: [StGIT PATCH 0/6] New and improved DAG appliedness series
From: Yann Dirson @ 2007-06-30 19:54 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20070610094322.12000.56284.stgit@bill>
Hi Karl,
On Sun, Jun 10, 2007 at 02:54:47AM -0700, Karl Hasselström wrote:
> This took a while, but here it is. (Actually, I finished this about a
> week ago, but had no Internet connection so I couldn't send it.)
Is this the latest version of the DAG patches, or is there maybe a
public repo where you push your work ?
It happens that my refactorings touches virtually everything, so there
will be conflicts, and the best thing to do is probably that I rebase
my work on yours.
Best regards,
--
Yann
^ permalink raw reply
* Re: Question about git-prune
From: walt @ 2007-06-30 20:06 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706301900290.4438@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 30 Jun 2007, walt wrote:
...
>> $git-prune
>> $git-fsck
>> dangling tree c642c018aa55d39fff061183f58062de9d8375ac
>> dangling commit e1341abc3759950e891822088cb0163b71b316b3
>> dangling commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4
>> dangling commit b82871b3c32faa8a317007f343fdf2d0ddc9954e
>
> Probably the objects were packed.
I also tried git-prune-packed, which also did nothing AFAICT.
> I do not understand why you use git-prune directly, to begin with. Why not
> use git-gc and be done with it?
It didn't exist when I started using git. I normally don't use
git-prune either, but in this case I was just scanning for problems
after switching from cg-update to git-pull.
git-gc did get rid of all the danglers even though git-prune didn't.
I'll do some investigating to find out why -- that should get me more
up to date with recent changes.
Thanks for your help.
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Junio C Hamano @ 2007-06-30 20:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706301231200.1172@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Well, we have a more serious issue, that is related, but has nothing to do
> with aliases.
>
> If you set an environment variable "diff.color=always", any script will
> get that behaviour, and not work the way it might expect.
>
> My point being that this has nothing to do with "git-diff" vs "git diff",
> and everything to do with default configurations. If you don't want people
> to be able to change fixed behaviour, you'd need to have a way to disable
> it.
That's exactly why we have told people to use plumbing in their
scripts, and git-diff-tree does not look at diff.color.
> Quite frankly, I think it's _easier_ to disable with "git xyzzy" than with
> "git-xyzzy", but hey, not a big deal. With "git xyzzy", we could add a
> generic flag like
>
> git - xyzzy
>
> to make the rule be that no configurations (_including_ aliases) are
> allowed to override default behaviour, which is much harder with the
> "git-xyzzy" format (since then it's invariably a per-command thing).
But that would break existing scripts wouldn't it?
^ permalink raw reply
* Re: Question about git-prune
From: Junio C Hamano @ 2007-06-30 20:12 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <f66d3l$sa6$1@sea.gmane.org>
walt <wa1ter@myrealbox.com> writes:
>> Probably the objects were packed.
>
> I also tried git-prune-packed, which also did nothing AFAICT.
Of course it wouldn't; prune-packed is to prune loose objects
that also appear in packs.
What is happening is:
- You create a pack that has everything reachable from refs at
one point;
- You pull or do your own development; the set of objects
reachable from refs change from the above set. This set is
superset of the above only if there is no rewind is
involved. Otherwise, some objects already packed in the
previous step are now unreachable.
- git-prune and git-prune-packed are about removing loose
objects. They never go into existing packs and eradicate
objects from them.
When you have unreachable cruft in packs, repacking is the only
way to rid them ("git repack -a -d", which is run by "git gc").
^ permalink raw reply
* Re: Question about git-prune
From: Johannes Schindelin @ 2007-06-30 20:18 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <f66d3l$sa6$1@sea.gmane.org>
Hi,
On Sat, 30 Jun 2007, walt wrote:
> Johannes Schindelin wrote:
> >
> > On Sat, 30 Jun 2007, walt wrote:
> ...
> > > $git-prune
> > > $git-fsck
> > > dangling tree c642c018aa55d39fff061183f58062de9d8375ac
> > > dangling commit e1341abc3759950e891822088cb0163b71b316b3
> > > dangling commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4
> > > dangling commit b82871b3c32faa8a317007f343fdf2d0ddc9954e
> >
> > Probably the objects were packed.
>
> I also tried git-prune-packed, which also did nothing AFAICT.
git-prune-packed prunes objects which are loose _and_ packed.
> > I do not understand why you use git-prune directly, to begin with. Why
> > not use git-gc and be done with it?
>
> It didn't exist when I started using git. I normally don't use
> git-prune either, but in this case I was just scanning for problems
> after switching from cg-update to git-pull.
Fair enough.
> git-gc did get rid of all the danglers even though git-prune didn't.
> I'll do some investigating to find out why -- that should get me more up
> to date with recent changes.
The thing you needed was actually git-repack (which is called with every
necessary option you need from git-gc).
Basically, your objects were dangling _and_ packed. Thus you had to repack
in order to get rid of them, but keep the others.
Ciao,
Dscho
^ permalink raw reply
* Non-http dumb protocols
From: Daniel Barkalow @ 2007-06-30 20:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Do we actually support local-fetch and ssh-fetch/ssh-push any more? They
seem to me to have been entirely supplanted with respect to functionality
for a long time now, but the programs are still there. This complicates
http-fetch, because only one -fetch can be linked into a binary as
currently designed, and we may want to make http-fetch builtin at some
point. Can we remove the other dumb protocols and merge fetch.c into
http-fetch.c?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Junio C Hamano @ 2007-06-30 20:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <7vy7i1b6bt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> Anyway, while actually removing the "git-xyzzy" things is not practical
>> right now, we can certainly start slowly to deprecate it internally inside
>> git itself - in the shell scripts we use, and the test vectors.
>
> So I am somewhat negative on this, unless there is a way for
> scripts to say "Even though I say 'git foo', I do mean 'git foo'
> not whatever the user has aliased".
Having said that, I am not opposed to encourage distros to set
gitexecdir to $(prefix)/libexec in their modified Makefile.
There is no reason to contaminate a directory on end users'
$PATH with hundreds of commands that begin with "git-" prefix.
In fact, I used to configure my copy of git with gitexecdir set
to outside my $PATH when we first started pushing it to make
sure everything works (I do not install git from distro on my
machine so I know I have only one instance of bin/git in my
path). It used to work, but I am no longer using that layout
these days, so it is entirely possible that we might have broken
the support along the way. And _that_ is worth fixing.
^ 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