* Re: [PATCH] Document git-stash
From: Johannes Schindelin @ 2007-07-01 22:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King,
しらいしななこ, GIT
In-Reply-To: <7vlkdz4wp3.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 1 Jul 2007, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> +(no subcommand)::
> >> +
> >> + Save your local modifications to a new 'stash', and run `git-reset
> >> + --hard` to revert them.
> >
> > For orthogonality's sake, should this be 'git-stash save', aliased to
> > just 'git-stash'? It would make this heading a little more intuitive,
> > and the very first paragraph (describing all of the modes) a little more
> > clear.
>
> I would further suggest that we _require_ 'git stash save' to
> create a new one and perhaps make the non-subcommand case run
> 'git stash list'. While I was trying the code out I
> accidentally created a new stash when I did not mean to, which
> pushed the stash I wanted to apply down in the list every time I
> made such a mistake.
Well, the normal thing you want to do if you say "git stash" is best
described by "Git, stash!".
However, unstash would by a nice feature. Not easy, but nice. Not easy,
because we would be actively outsmarting the reflog machinery we use for
the stash.
Ciao,
Dscho
^ permalink raw reply
* (unknown)
From: Sean D'Epagnier @ 2007-07-01 18:25 UTC (permalink / raw)
To: git
unsubscribe git
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-07-02 0:16 UTC (permalink / raw)
To: git
In-Reply-To: <7v7ipsz7vr.fsf@assigned-by-dhcp.pobox.com>
Will do a 1.5.2.3 with the tip of 'maint' probably mid-week and
a 1.5.3-rc1 at about the same time from 'master', hopefully with
a few topics that have been in 'next', and also some "discussed
but forgotten" fixes on the list if somebody kindly can remind
me ;-).
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Frank Lichtenheld (2):
config: Complete documentation of --get-regexp
config: Change output of --get-regexp for valueless keys
Linus Torvalds (1):
Fix zero-object version-2 packs
Matt Kraai (1):
Correct the name of NO_R_TO_GCC_LINKER in the comment describing
it.
Sam Vilain (3):
cleanup merge-base test script
repack: improve documentation on -a option
git-remote: document -n
Shawn O. Pearce (5):
git-gui: Correctly install to /usr/bin on Cygwin
git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
git-gui: Don't require $DISPLAY just to get --version
git-gui: Don't nice git blame on MSYS as nice is not supported
git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
Sven Verdoolaege (1):
Ignore submodule commits when fetching over dumb protocols
* The 'master' branch has these since the last announcement
in addition to the above.
Adam Roben (2):
git-send-email: Add --threaded option
git-send-email: make options easier to configure.
Alex Riesen (1):
Avoid perl in t1300-repo-config
Alexandre Vassalotti (1):
git-tag: Fix "can't shift that many".
Brian Gernhardt (1):
Fix t5516-fetch for systems where `wc -l` outputs whitespace.
Carlos Rica (3):
Fix git-stripspace to process correctly long lines and spaces.
Add test script for git-stripspace.
Add test-script for git-tag
Frank Lichtenheld (2):
config: Add --null/-z option for null-delimted output
config: add support for --bool and --int while setting values
Gerrit Pape (1):
git-cvsimport: force checkout of working tree after initial import
Jim Meyering (3):
detect close failure on just-written file handles
Don't ignore a pack-refs write failure
git-log: detect dup and fdopen failure
Johannes Schindelin (2):
t7004: ship trustdb to avoid gpg warnings
git add: respect core.filemode with unmerged entries
Junio C Hamano (2):
Add core.quotepath configuration variable.
Update draft Release Notes for 1.5.3
Linus Torvalds (3):
Clean up internal command handling
Check for IO errors after running a command
git: Try a bit harder not to lose errno in stdio
Mark Levedahl (5):
gitk: Make selection highlight color configurable
gitk: Update fontsize in patch / tree list
gitk: Allow specifying tabstop as other than default 8 characters.
gitk: Use a spinbox for setting tabstop settings
gitk: Update selection background colorbar in prefs dialog
Matthias Lederhofer (10):
rev-parse: document --is-inside-git-dir
rev-parse: introduce --is-bare-repository
test git rev-parse
introduce GIT_WORK_TREE to specify the work tree
Use new semantics of is_bare/inside_git_dir/inside_work_tree
extend rev-parse test for --is-inside-work-tree
test GIT_WORK_TREE
setup_git_directory: fix segfault if repository is found in cwd
filter-branch: always export GIT_DIR if it is set
make git barf when an alias changes environment variables
Michael Krelin (1):
git-svn: honor ~/.subversion/ client cert file settings.
Paul Mackerras (18):
gitk: Use the -q flag to git checkout
gitk: New infrastructure for working out branches & previous/next
tags
gitk: Don't try to list large numbers of tags or heads in the
details pane
gitk: Add some more comments to the optimize_rows procedure
gitk: Improve the behaviour of the initial selection
gitk: Implement a simple scheduler for the compute-intensive stuff
gitk: Cope with commit messages with carriage-returns and initial
blank lines
gitk: Disable the head context menu entries for the checked-out
branch
gitk: Store ids in rowrangelist and idrowranges rather than row
numbers
gitk: New algorithm for drawing the graph lines
gitk: Show local uncommitted changes as a fake commit
gitk: Speed up the reading of references
gitk: Get rid of the childlist variable
gitk: Add a "reset branch to here" row context-menu operation
gitk: Limit how often we change the canvas scrolling region
gitk: Fix bug causing nearby tags/heads to sometimes not be
displayed
gitk: Improve handling of whitespace and special chars in filenames
gitk: Add a progress bar to show progress while resetting
Quy Tonthat (1):
git.spec: RPM failed, looking for wrong files.
René Scharfe (2):
diffcore-rename: don't change similarity index based on basename
equality
diff: round down similarity index
Sam Vilain (2):
git-svn: use git-log rather than rev-list | xargs cat-file
git-svn: cache max revision in rev_db databases
Shawn O. Pearce (3):
git-gui: Quiet our installation process
Teach bash how to complete +refspec on git-push
Correct usages of sed in git-tag for Mac OS X
Simon Hausmann (1):
git-new-workdir: Fix shell warning about operator == used with
test.
Theodore Ts'o (1):
Don't fflush(stdout) when it's not helpful
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-07-02 0:16 UTC (permalink / raw)
To: git
In-Reply-To: <7v645cz7vm.fsf@assigned-by-dhcp.pobox.com>
Here are the topics that have been cooking in 'next'.
* ns/stash (Sun Jul 1 15:29:01 2007 -0700) 3 commits
+ git-stash: require "save" to be explicit and update documentation
+ Document git-stash
+ Add git-stash script
I am hoping this would appear in 1.5.3; it would help what many
people asked (and later we probably would want to invoke it in
git-merge to have an option to automated the process further).
* js/rebase (Mon Jun 25 18:59:43 2007 +0100) 6 commits
+ Teach rebase -i about --preserve-merges
+ rebase -i: provide reasonable reflog for the rebased branch
+ rebase -i: several cleanups
+ ignore git-rebase--interactive
+ Teach rebase an interactive mode
+ Move the pick_author code to git-sh-setup
Will merge.
* jc/diffcore (Thu Jun 28 23:14:13 2007 -0700) 4 commits
+ diffcore-delta.c: Ignore CR in CRLF for text files
+ diffcore-delta.c: update the comment on the algorithm.
+ diffcore_filespec: add is_binary
+ diffcore_count_changes: pass diffcore_filespec
Will merge; although the CRLF stuff itself would probably not
help anybody in real-life, the change in the interface to allow
further enhancement would be a good thing.
* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit
+ git-svn: allow dcommit to retain local merge information
Any negative feedback on this? Otherwise will merge.
* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits
+ Quiet the output from git-init when cloning, if requested.
+ Add an option to quiet git-init.
Opinions?
^ permalink raw reply
* [PATCH] format-patch: Add format.subjectprefix config option
From: Adam Roben @ 2007-07-02 0:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Adam Roben
This change lets you use the format.subjectprefix config option to override the
default subject prefix.
Signed-off-by: Adam Roben <aroben@apple.com>
---
Documentation/git-format-patch.txt | 5 +-
builtin-log.c | 9 +++
revision.c | 1 -
t/t4013-diff-various.sh | 2 +
...ff.config_format.subjectprefix_DIFFERENT_PREFIX | 2 +
...ormat-patch_--inline_--stdout_initial..master^^ | 60 ++++++++++++++++++++
6 files changed, 76 insertions(+), 3 deletions(-)
create mode 100644 t/t4013/diff.config_format.subjectprefix_DIFFERENT_PREFIX
create mode 100644 t/t4013/diff.format-patch_--inline_--stdout_initial..master^^
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 647de90..e563810 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -126,12 +126,13 @@ not add any suffix.
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each
-message in the repository configuration. Also you can specify
-the default suffix different from the built-in one:
+message in the repository configuration. You can also specify
+new defaults for the subject prefix and file suffix.
------------
[format]
headers = "Organization: git-foo\n"
+ subjectprefix = CHANGE
suffix = .txt
------------
diff --git a/builtin-log.c b/builtin-log.c
index a4186ea..5dc2c1c 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -265,6 +265,7 @@ static int istitlechar(char c)
static char *extra_headers = NULL;
static int extra_headers_size = 0;
+static const char *fmt_patch_subject_prefix = "PATCH";
static const char *fmt_patch_suffix = ".patch";
static int git_format_config(const char *var, const char *value)
@@ -290,6 +291,13 @@ static int git_format_config(const char *var, const char *value)
if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
return 0;
}
+ if (!strcmp(var, "format.subjectprefix")) {
+ if (!value)
+ die("format.subjectprefix without value");
+ fmt_patch_subject_prefix = xstrdup(value);
+ return 0;
+ }
+
return git_log_config(var, value);
}
@@ -459,6 +467,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
rev.diffopt.msg_sep = "";
rev.diffopt.recursive = 1;
+ rev.subject_prefix = fmt_patch_subject_prefix;
rev.extra_headers = extra_headers;
/*
diff --git a/revision.c b/revision.c
index 7834bb1..5184716 100644
--- a/revision.c
+++ b/revision.c
@@ -667,7 +667,6 @@ void init_revisions(struct rev_info *revs, const char *prefix)
revs->min_age = -1;
revs->skip_count = -1;
revs->max_count = -1;
- revs->subject_prefix = "PATCH";
revs->prune_fn = NULL;
revs->prune_data = NULL;
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 8f4c29a..b453b42 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -242,6 +242,8 @@ format-patch --inline --stdout initial..side
format-patch --inline --stdout initial..master^
format-patch --inline --stdout initial..master
format-patch --inline --stdout --subject-prefix=TESTCASE initial..master
+config format.subjectprefix DIFFERENT_PREFIX
+format-patch --inline --stdout initial..master^^
diff --abbrev initial..side
diff -r initial..side
diff --git a/t/t4013/diff.config_format.subjectprefix_DIFFERENT_PREFIX b/t/t4013/diff.config_format.subjectprefix_DIFFERENT_PREFIX
new file mode 100644
index 0000000..78f8970
--- /dev/null
+++ b/t/t4013/diff.config_format.subjectprefix_DIFFERENT_PREFIX
@@ -0,0 +1,2 @@
+$ git config format.subjectprefix DIFFERENT_PREFIX
+$
diff --git a/t/t4013/diff.format-patch_--inline_--stdout_initial..master^^ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master^^
new file mode 100644
index 0000000..b8e81e1
--- /dev/null
+++ b/t/t4013/diff.format-patch_--inline_--stdout_initial..master^^
@@ -0,0 +1,60 @@
+$ git format-patch --inline --stdout initial..master^^
+From 1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44 Mon Sep 17 00:00:00 2001
+From: A U Thor <author@example.com>
+Date: Mon, 26 Jun 2006 00:01:00 +0000
+Subject: [DIFFERENT_PREFIX] Second
+MIME-Version: 1.0
+Content-Type: multipart/mixed; boundary="------------g-i-t--v-e-r-s-i-o-n"
+
+This is a multi-part message in MIME format.
+--------------g-i-t--v-e-r-s-i-o-n
+Content-Type: text/plain; charset=UTF-8; format=fixed
+Content-Transfer-Encoding: 8bit
+
+
+This is the second commit.
+---
+ dir/sub | 2 ++
+ file0 | 3 +++
+ file2 | 3 ---
+ 3 files changed, 5 insertions(+), 3 deletions(-)
+ delete mode 100644 file2
+--------------g-i-t--v-e-r-s-i-o-n
+Content-Type: text/x-patch; name="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
+Content-Transfer-Encoding: 8bit
+Content-Disposition: inline; filename="1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44.diff"
+
+diff --git a/dir/sub b/dir/sub
+index 35d242b..8422d40 100644
+--- a/dir/sub
++++ b/dir/sub
+@@ -1,2 +1,4 @@
+ A
+ B
++C
++D
+diff --git a/file0 b/file0
+index 01e79c3..b414108 100644
+--- a/file0
++++ b/file0
+@@ -1,3 +1,6 @@
+ 1
+ 2
+ 3
++4
++5
++6
+diff --git a/file2 b/file2
+deleted file mode 100644
+index 01e79c3..0000000
+--- a/file2
++++ /dev/null
+@@ -1,3 +0,0 @@
+-1
+-2
+-3
+
+--------------g-i-t--v-e-r-s-i-o-n--
+
+
+$
--
1.5.2.2.619.g06f59-dirty
^ permalink raw reply related
* Re: [PATCH] contrib/hooks: add post-update hook for updating working copy
From: Junio C Hamano @ 2007-07-02 1:10 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <46882AF2.6020705@vilain.net>
Sam Vilain <sam@vilain.net> writes:
> Basically I'm trying to figure out "does the current index have any
> uncommitted changes". If it matches the tree from the previous (handful
> of) ref(s), then the answer is "no". If we can't find it anywhere then
> it's probably got staged changes, and short of trying to move the
> changes forward, we should stop.
The fact that the index does not match the HEAD means that the
user (possibly not the one who is pushing) is in the middle of
doing something. A tree that happens to match that state exists
in the recent reflog history would only mean that the same state
exists _somewhere_; it does not mean it is easy for the end user
to go back to it at all.
>> But more importantly, why is it justified to throw away such
>> files to begin with?
>
> Because we've already previously decided that they are safely stowed in
> a previous (via time/reflog) revision of the current branch.
The user may have spent hours to come up to that state while
doing something we do not have any way of knowing what, and this
"heuristic" is allowing to lose that. As you say, we do not
lose the tree from the repository, but we lose track of which
state the user was interested in. I find that unjustified.
> Perhaps it would make sense to do this check in the "update" hook as
> well, thereby chmod +x refuses to allow a push that touches the
> currently checked out branch.
Having the check in update to prevent it makes sense,
independently.
>> The longer I look at this patch, the more inclined I become to
>> say that the only part that is worth saving is the next hunk.
Actually, I think "the first sentence of the output in the next
hunk" was what I meant. That is, "we are not updating it
because it is dirty and you cannot get back to the original
state if this was a mistake". And not updating the index nor
the working tree.
How about doing something simpler, more predicatable and safer,
like this...
* If HEAD/index/working tree match, then obviously we can do an
equivalent of "reset --hard". There is little chance that
this is a wrong thing to do, and even when the user did not
want that happen, the user can easily recover with for
example "git checkout @{1} .". So I am not opposed to
updating the index/working tree in this case at all.
* Otherwise, especially when HEAD and index do not match,
touching index nor working tree is absolutely a no-no,
without giving the user to sort the mess out. So either in
"update" hook you prevent it from happening.
Later, when we have git-stash, we can do a bit better in a dirty
working tree. We could make a stash of the state _before_
updating the tip of the current branch, and let the push update
the tip, and do an equivalent of "reset --hard". Unstashing the
state on top of the updated tip could fail, but at that point,
the user has the choice of making a new branch (or use detached
HEAD) at @{1} (that is, the HEAD before the push updated it) and
then unstash the state on top of it to recreate the state before
the push made a mess.
^ permalink raw reply
* [PATCH] "git-push $URL" without refspecs pushes only matching branches
From: Junio C Hamano @ 2007-07-02 2:00 UTC (permalink / raw)
To: git; +Cc: Andy Parkins, Linus Torvalds, plexq
In-Reply-To: <7vk5u9hzv9.fsf@assigned-by-dhcp.pobox.com>
When "git push" is run without any refspec (neither on the
command line nor in the config), we used to push "matching refs"
in the sense that anything under refs/ hierarchy that exist on
both ends were updated. This used to be a sane default for
publishing your repository to another back when we did not have
refs/remotes/ hierarchy, but it does not make much sense these
days.
This changes the semantics to push only "matching branches".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Probably we should not do push anything other than refs/heads/
> when we do "matching refs"
>
> I think what we might want to do around this area are:
>
> - Don't change anything, if the command line says refspec, or
> the remote has push refspec specified.
>
> - When doing 'matching refs', do it only under refs/heads/.
>
> - Ship with a receive-pack hook that attempts a 3-way merge
> update when the currently checked out branch is updated.
>
> Additionally we can give an option to "git clone" (or "git
> remote add") to arrange the cross-push configuration for
> mothership-satellite Andy showed in the clone's .git/config;
> but I think that is a separate issue.
remote.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index 500ca4d..cf98a44 100644
--- a/remote.c
+++ b/remote.c
@@ -544,6 +544,13 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
if (!pat)
continue;
}
+ else if (prefixcmp(src->name, "refs/heads/"))
+ /*
+ * "matching refs"; traditionally we pushed everything
+ * including refs outside refs/heads/ hierarchy, but
+ * that does not make much sense these days.
+ */
+ continue;
if (pat) {
const char *dst_side = pat->dst ? pat->dst : pat->src;
^ permalink raw reply related
* Re: [PATCH] git-mergetool: add support for ediff
From: Theodore Tso @ 2007-07-02 2:04 UTC (permalink / raw)
To: Jason Sewall; +Cc: Sam Vilain, Junio C Hamano, git
In-Reply-To: <20070629040328.GG29279@thunk.org>
On Fri, Jun 29, 2007 at 12:03:28AM -0400, Theodore Tso wrote:
> I'll have to look at the two and see why people like one over the
> other, and then we'll have to pick which one should be the default.
> Although as I've said, past a certain point people should just put
> their personal preference in .gitconfig.
After looking at ediff, it is definitely the more polished and
featureful compared to emerge --- except in one critical area, which
is calling as a mergeing tool from a shell script or command line.
Ediff fundamentally assumes that it fired off from inside an emacs
environment, whereas emerge is much friendly as an external merge
program.
This can be shown in the relatively easy way emerge can be run from
the command-line:
emacs -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$path"
... where as with ediff, you have to run it this way:
emacs --eval "(ediff-merge-files-with-ancestor \"$LOCAL\" \"$REMOTE\" \"$BASE\" nil \"$path\")"
Unfortunately, it's not enough. Ediff doesn't have an "abort" command
which returns a non-zero exit status, and when you use the "quit"
command, it asks you a series of obnoxious questions:
Quit this Ediff session? (y or n)
File /usr/projects/git/test/testfile.c exists, overwrite? (y or n)
Merge buffer saved in /usr/projects/git/test/testfile.c
<delay for 3 annoying seconds>
Merge buffer saved. Now kill the buffer? (y or n)
... and then it leaves you in the emacs window, and you have to type
^X^C by hand.
So while ediff is more featureful, its integration is so lacking that
it is incredibly annoying to use.
Which leaves us with the interesting question. We could just
integrate it, but not make it the default (the above makes ediff just
far too annoying for a user who is not expecting it).
Alternatively, we could patch around the problem. The following emacs
lisp code fixes the ediff issues:
(defun ediff-write-merge-buffer ()
(let ((file ediff-merge-store-file))
(set-buffer ediff-buffer-C)
(write-region (point-min) (point-max) file)
(message "Merge buffer saved in: %s" file)
(set-buffer-modified-p nil)
(sit-for 1)))
(setq ediff-quit-hook 'kill-emacs
ediff-quit-merge-hook 'ediff-write-merge-buffer)
But the only clean way of adding that to git-mergetool would be something like this:
emacs --eval "(progn (defun ediff-write-merge-buffer () (let ((file ediff-merge-store-file)) (set-buffer ediff-buffer-C) (write-region (point-min) (point-max) file) (message \"Merge buffer saved in: %s\" file) (set-buffer-modified-p nil) (sit-for 1))) (setq ediff-quit-hook 'kill-emacs ediff-quit-merge-hook 'ediff-write-merge-buffer) (ediff-merge-files-with-ancestor \"$LOCAL\" \"$REMOTE\" \"$BASE\" nil \"$path\")"
But that seems too ugly to live, and it could break in the future if
ediff ever changes some of its internal variables.
Alternatively, we could file a bug report with the ediff folks, and
request that they add an 'ediff-files-with-ancestor-command and
'ediff-files-command just as emerge does. The problem with that
approach is that ediff is shipped with emacs, and emacs has a release
cycle measured in **years**.
So my current thinking is that ediff will *not* be the default for
git-mergetool if emacs is present, and that emerge will be used for
now, because of these problems.
Comments?
- Ted
^ permalink raw reply
* Re: [PATCH] git-mergetool: add support for ediff
From: Junio C Hamano @ 2007-07-02 2:32 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jason Sewall, Sam Vilain, git
In-Reply-To: <20070702020401.GD28917@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> Unfortunately, it's not enough. Ediff doesn't have an "abort" command
> which returns a non-zero exit status, and when you use the "quit"
> command, it asks you a series of obnoxious questions:
>
> ...
> Alternatively, we could patch around the problem. The following emacs
> lisp code fixes the ediff issues:
But that would be changing the behaviour globally, and not
limited to the particular session invoked from git-mergetool,
wouldn't it? If that is the case it would be a hard sell to
Emacs users, especially the ones that keep their Emacs running
forever and have emacsclient as their EDITOR, I would think.
^ permalink raw reply
* Re: [PATCH] git-mergetool: add support for ediff
From: Theodore Tso @ 2007-07-02 3:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jason Sewall, Sam Vilain, git
In-Reply-To: <7v1wfr1qn8.fsf@assigned-by-dhcp.cox.net>
On Sun, Jul 01, 2007 at 07:32:59PM -0700, Junio C Hamano wrote:
> Theodore Tso <tytso@mit.edu> writes:
>
> > Unfortunately, it's not enough. Ediff doesn't have an "abort" command
> > which returns a non-zero exit status, and when you use the "quit"
> > command, it asks you a series of obnoxious questions:
> >
> > ...
> > Alternatively, we could patch around the problem. The following emacs
> > lisp code fixes the ediff issues:
>
> But that would be changing the behaviour globally, and not
> limited to the particular session invoked from git-mergetool,
> wouldn't it? If that is the case it would be a hard sell to
> Emacs users, especially the ones that keep their Emacs running
> forever and have emacsclient as their EDITOR, I would think.
The emacs lisp code I gave there was the minimal necessary so it
could be passed on the command-line; I was trying to keep it small.
Obviously, the patch that would have to get sent to the ediff folks
would have to be much more generalized --- in fact, probably the right
thing to do is to send a full patch that actually implemented
ediff-merge-files-command and ediff-merge-files-with-ancestoers-commands.
As far as people using emacsclient as their editor, it would be simple
enough to have the emacs lisp code test to see if
server-buffer-clients is non-nill; if it is, then we know that this
merge request was trigered by emacsclient, and so (server-done) should
be called instead of (kill-emacs). Emerge does not do this; arguably
this is a bug in emerge.
The other way we could deal with this problem is to fire up a separate
emacs even if EDITOR is emacsclient, on the theory that
EDITOR=emacsclient meants that the user prefers emacs, but it doesn't
necessarily mean that we have to *use* emacsclient, especially when
emerge currently doesn't DTRT with emacsclient.
One thing that did cross my mind is that we could put code which
patched ediff.el and emerge.el in /usr/share/git/lisp/... and then
passed called emacs with something like this "emacs -l
$sharedir/lisp/ediff-patches.el ...". But this implies packaging
emacs lisp files with git, and I'm not at ALL sure we want to go
there. Personally, I still like kdiff3 as my personal favorite
mergetool, and given that emacs starts up pretty fast these days, I've
given up on emacsclient, but I know there are certainly people who use
them.
(Mmmm...., I just pulled down an early emacs 23 snapshot with Xft
support enabled, so I can enjoy the anti-aliased font goodness. Even
with all of the Gtk and Xft bloat, the emacs 23 snapshot is still
quick snappy to fire up.)
- Ted
^ permalink raw reply
* Re: [PATCH] Document git-stash
From: Jeff King @ 2007-07-02 4:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ, GIT,
Johannes Schindelin
In-Reply-To: <7vps3b4xcj.fsf@assigned-by-dhcp.cox.net>
On Sun, Jul 01, 2007 at 02:39:56PM -0700, Junio C Hamano wrote:
> For paths that are cleanly merged with this three-way merge,
> merge-recursive updates the working tree and the index. That
> means if you do "git diff", you would not see the local changes
> that were carried forward would not be visible, and you would
> need "git diff HEAD" to view them. I found it confusing, and
> that was the suggestion I sent was about. Nana's "3rd try", which
> I applied and pushed to 'next', addresses this issue by running
> "read-tree --reset $c_tree" (where $c_tree is the contents of
> the index before replaying the stash).
>
> This is not ideal. We would want to see "git diff" for such a
> path show difference similar to difference between I and W.
Ah, I get it now. Thanks for the explanation.
I see you gutted the confusing text from the manpage...I think what you
have now is conceptually much simpler, and it won't bite anyone unless
they are trying to do something clever with the index. In which case I
hope they will be able to use the description of how the stash is stored
to poke around.
-Peff
^ permalink raw reply
* Re: [PATCH] Document git-stash
From: Jeff King @ 2007-07-02 4:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ, GIT,
Johannes Schindelin
In-Reply-To: <7vlkdz4wp3.fsf@assigned-by-dhcp.cox.net>
On Sun, Jul 01, 2007 at 02:54:00PM -0700, Junio C Hamano wrote:
> I would further suggest that we _require_ 'git stash save' to
> create a new one and perhaps make the non-subcommand case run
> 'git stash list'. While I was trying the code out I
> accidentally created a new stash when I did not mean to, which
> pushed the stash I wanted to apply down in the list every time I
> made such a mistake.
I think that makes sense...it's somehow cleaner to me if the
non-subcommand case doesn't make any changes (maybe just because I like
to explore commands by running them).
I see you have already applied this change. However, you missed a spot
in the documentation. Patch will follow, along with a couple of minor
cleanups for the script.
-Peff
^ permalink raw reply
* [PATCH] git-stash: fix "no arguments" case in documentation
From: Jeff King @ 2007-07-02 4:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: nanako3, git
Commit 9488e875 changed this from 'save' to 'list', but
missed this spot in the documentation.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-stash.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 4815965..4dc344d 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -21,8 +21,8 @@ and reverts the working directory to match the `HEAD` commit.
The modifications stashed away by this command can be listed with
`git-stash list`, inspected with `git-stash show`, and restored
(potentially on top of a different commit) with `git-stash apply`.
-The default operation when called without options is to save the
-changes away.
+Calling git-stash without any arguments is equivalent to `git-stash
+list`.
The latest stash you created is stored in `$GIT_DIR/refs/stash`; older
stashes are found in the reflog of this reference and can be named using
--
1.5.2.2.1452.g896f6
^ permalink raw reply related
* [PATCH] git-stash: fix "can't shift that many" with no arguments
From: Jeff King @ 2007-07-02 4:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: nanako3, git
Signed-off-by: Jeff King <peff@peff.net>
---
git-stash.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index ec18ef6..7644bd5 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -133,7 +133,7 @@ apply_stash () {
# Main command set
case "$1" in
list | '')
- shift
+ test $# -gt 0 && shift
if test $# = 0
then
set x -n 10
--
1.5.2.2.1452.g896f6
^ permalink raw reply related
* [PATCH] git-stash: don't complain when listing in a repo with no stash
From: Jeff King @ 2007-07-02 4:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: nanako3, git
Previously, the git-log invocation would complain if a repo
had not had any stashes created in it yet:
$ git-init
$ git-stash
fatal: ambiguous argument 'refs/stash': unknown revision or
path not in the working tree.
Use '--' to separate paths from revisions
Instead, we only call git-log if we actually have a
refs/stash. We could alternatively create the ref when any
stash command is called, but it's better for the 'list'
command to not require write access to the repo.
Signed-off-by: Jeff King <peff@peff.net>
---
git-stash.sh | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 7644bd5..18d3322 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -76,7 +76,12 @@ save_stash () {
printf >&2 'Saved WIP on %s\n' "$msg"
}
+have_stash () {
+ git-rev-parse --verify $ref_stash >/dev/null 2>&1
+}
+
list_stash () {
+ have_stash || return 0
git-log --pretty=oneline -g "$@" $ref_stash |
sed -n -e 's/^[.0-9a-f]* refs\///p'
}
--
1.5.2.2.1452.g896f6
^ permalink raw reply related
* Re: [PATCH] git-mergetool: add support for ediff
From: Junio C Hamano @ 2007-07-02 4:49 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jason Sewall, Sam Vilain, git
In-Reply-To: <20070702030521.GA4798@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> One thing that did cross my mind is that we could put code which
> patched ediff.el and emerge.el in /usr/share/git/lisp/... and then
> passed called emacs with something like this "emacs -l
> $sharedir/lisp/ediff-patches.el ...". But this implies packaging
> emacs lisp files with git, and I'm not at ALL sure we want to go
> there. ...
I hope not.
> ... Personally, I still like kdiff3 as my personal favorite
> mergetool, and given that emacs starts up pretty fast these days, I've
> given up on emacsclient, but I know there are certainly people who use
> them.
The reason I personally use emacsclient is not about the
start-up delay, but with the access to existing buffers,
keyboard macros, Gnus buffers, ... IOW the access to the
"session" while editing. I suspect people with long running
Emacs session use emacsclient for that reason.
^ permalink raw reply
* Re: [PATCH] git-stash: don't complain when listing in a repo with no stash
From: しらいしななこ @ 2007-07-02 5:02 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20070702042124.GA29479@coredump.intra.peff.net>
Quoting Jeff King <peff@peff.net>:
> Previously, the git-log invocation would complain if a repo
> had not had any stashes created in it yet:
>
> $ git-init
> $ git-stash
> fatal: ambiguous argument 'refs/stash': unknown revision or
> path not in the working tree.
> Use '--' to separate paths from revisions
>
> Instead, we only call git-log if we actually have a
> refs/stash. We could alternatively create the ref when any
> stash command is called, but it's better for the 'list'
> command to not require write access to the repo.
>
> Signed-off-by: Jeff King <peff@peff.net>
Thank you for correcting the bugs I introduced.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Finally - A spam blocker that actually works.
http://www.bluebottle.com
^ permalink raw reply
* [PATCH] Documentation: quote {non-attributes} for asciidoc
From: Jeff King @ 2007-07-02 5:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Asciidoc treats {foo} as an attribute to be substituted; if
'foo' doesn't exist as an attribute, then the entire line
gets dropped. When the literal {foo} is desired, \{foo} is
required.
The exceptions to this rule are:
- inside literal blocks
- if the 'foo' contains non-alphanumeric characters (e.g.,
{foo|bar} is assumed not to be an attribute)
Signed-off-by: Jeff King <peff@peff.net>
---
I noticed this because one of the dropped lines was causing asciidoc to
generate invalid XML for the git-stash man page. However, you can see it
in action in other pages here:
http://www.kernel.org/pub/software/scm/git/docs/git-branch.html
Check out the '-l' option.
I think this gets all of them (except for the release notes, which
aren't built). Unfortunately, asciidoc seems to have no mode where it
tells me which lines it has dropped.
I don't know how much we can rely on the "if it doesn't look like an
attribute name, print it literally" behavior. It certainly is the case
with asciidoc 8.2.1, but I didn't try other versions.
Finally, this would all be much simpler if asciidoc treated non-existant
attributes as literal strings. I assume the line-dropping is to allow
them to work as a primitive conditional.
Documentation/git-branch.txt | 2 +-
Documentation/git-checkout.txt | 2 +-
Documentation/git-receive-pack.txt | 10 +++++-----
Documentation/git-rev-list.txt | 4 ++--
Documentation/git-stash.txt | 8 ++++----
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 8d72bb9..9713f90 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -56,7 +56,7 @@ OPTIONS
-l::
Create the branch's ref log. This activates recording of
all changes to made the branch ref, enabling use of date
- based sha1 expressions such as "<branchname>@{yesterday}".
+ based sha1 expressions such as "<branchname>@\{yesterday}".
-f::
Force the creation of a new branch even if it means deleting
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index ea26da8..a6571d2 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -64,7 +64,7 @@ OPTIONS
-l::
Create the new branch's ref log. This activates recording of
all changes to made the branch ref, enabling use of date
- based sha1 expressions such as "<branchname>@{yesterday}".
+ based sha1 expressions such as "<branchname>@\{yesterday}".
-m::
If you have local modifications to one or more files that
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index 6914aa5..4ef1840 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -48,8 +48,8 @@ standard input of the hook will be one line per ref to be updated:
The refname value is relative to $GIT_DIR; e.g. for the master
head this is "refs/heads/master". The two sha1 values before
each refname are the object names for the refname before and after
-the update. Refs to be created will have sha1-old equal to 0{40},
-while refs to be deleted will have sha1-new equal to 0{40}, otherwise
+the update. Refs to be created will have sha1-old equal to 0\{40},
+while refs to be deleted will have sha1-new equal to 0\{40}, otherwise
sha1-old and sha1-new should be valid objects in the repository.
This hook is called before any refname is updated and before any
@@ -71,7 +71,7 @@ The refname parameter is relative to $GIT_DIR; e.g. for the master
head this is "refs/heads/master". The two sha1 arguments are
the object names for the refname before and after the update.
Note that the hook is called before the refname is updated,
-so either sha1-old is 0{40} (meaning there is no such ref yet),
+so either sha1-old is 0\{40} (meaning there is no such ref yet),
or it should match what is recorded in refname.
The hook should exit with non-zero status if it wants to disallow
@@ -96,8 +96,8 @@ The refname value is relative to $GIT_DIR; e.g. for the master
head this is "refs/heads/master". The two sha1 values before
each refname are the object names for the refname before and after
the update. Refs that were created will have sha1-old equal to
-0{40}, while refs that were deleted will have sha1-new equal to
-0{40}, otherwise sha1-old and sha1-new should be valid objects in
+0\{40}, while refs that were deleted will have sha1-new equal to
+0\{40}, otherwise sha1-old and sha1-new should be valid objects in
the repository.
Using this hook, it is easy to generate mails describing the updates
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 32cb13f..20dcac6 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -284,9 +284,9 @@ excluded from the output.
+
With '\--pretty' format other than oneline (for obvious reasons),
this causes the output to have two extra lines of information
-taken from the reflog. By default, 'commit@{Nth}' notation is
+taken from the reflog. By default, 'commit@\{Nth}' notation is
used in the output. When the starting commit is specified as
-'commit@{now}', output also uses 'commit@{timestamp}' notation
+'commit@{now}', output also uses 'commit@\{timestamp}' notation
instead. Under '\--pretty=oneline', the commit message is
prefixed with this information on the same line.
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 4dc344d..b7d263d 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -26,8 +26,8 @@ list`.
The latest stash you created is stored in `$GIT_DIR/refs/stash`; older
stashes are found in the reflog of this reference and can be named using
-the usual reflog syntax (e.g. `stash@{1}` is the most recently
-created stash, `stash@{2}` is the one before it, `stash@{2.hours.ago}`
+the usual reflog syntax (e.g. `stash@\{1}` is the most recently
+created stash, `stash@\{2}` is the one before it, `stash@\{2.hours.ago}`
is also possible).
OPTIONS
@@ -41,7 +41,7 @@ save::
list::
List the stashes that you currently have. Each 'stash' is listed
- with its name (e.g. `stash@{0}` is the latest stash, `stash@{1} is
+ with its name (e.g. `stash@\{0}` is the latest stash, `stash@\{1} is
the one before, etc.), the name of the branch that was current when the
stash was made, and a short description of the commit the stash was
based on.
@@ -57,7 +57,7 @@ show [<stash>]::
stashed state and its original parent. When no `<stash>` is given,
shows the latest one. By default, the command shows the diffstat, but
it will accept any format known to `git-diff` (e.g., `git-stash show
- -p stash@{2}` to view the second most recent stash in patch form).
+ -p stash@\{2}` to view the second most recent stash in patch form).
apply [<stash>]::
--
1.5.2.2.1452.g896f6
^ permalink raw reply related
* [PATCH] Documentation: minor cleanups to branch/checkout wording
From: Jeff King @ 2007-07-02 5:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Change "to made" to "made to", which is a typo. Use "reflog"
instead of "ref log", which is used elsewhere throughout the
documentation.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-branch.txt | 6 +++---
Documentation/git-checkout.txt | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 9713f90..bb6b57d 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -41,7 +41,7 @@ to happen.
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
-has a ref log then the ref log will also be deleted. Use -r together with -d
+has a reflog then the reflog will also be deleted. Use -r together with -d
to delete remote-tracking branches.
@@ -54,8 +54,8 @@ OPTIONS
Delete a branch irrespective of its index status.
-l::
- Create the branch's ref log. This activates recording of
- all changes to made the branch ref, enabling use of date
+ Create the branch's reflog. This activates recording of
+ all changes made to the branch ref, enabling use of date
based sha1 expressions such as "<branchname>@\{yesterday}".
-f::
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index a6571d2..818b720 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -62,8 +62,8 @@ OPTIONS
configuration variable.
-l::
- Create the new branch's ref log. This activates recording of
- all changes to made the branch ref, enabling use of date
+ Create the new branch's reflog. This activates recording of
+ all changes made to the branch ref, enabling use of date
based sha1 expressions such as "<branchname>@\{yesterday}".
-m::
--
1.5.2.2.1452.g896f6
^ permalink raw reply related
* t3902-quoted.sh broken on cygwin
From: Alex Riesen @ 2007-07-02 8:46 UTC (permalink / raw)
To: Git Mailing List
... and I suspect it is broken on MacOSX as well.
I suggest we disable the test completely on Cygwin/MinGW,
and after a test of course, on MacOSX.
The problem is the filesystems deficiencies again (HT and LF
can't be used in the filenames on Windows, and the unicode
characters may get broken on MacOSX).
^ permalink raw reply
* Re: Bug: segfault during git-prune
From: Andy Parkins @ 2007-07-02 10:00 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <alpine.LFD.0.98.0706281525460.8675@woody.linux-foundation.org>
On Thursday 2007 June 28, Linus Torvalds wrote:
> Anyway, if that patch works for you, I'd suggest you just pass it on to
> Junio (and feel free to add my "Signed-off-by:" on it - but conditional on
> you having actually tested it).
Okay; tested with this patch, but no change in behaviour.
$ git-prune
error: Object 228f8065b930120e35fc0c154c237487ab02d64a is a blob, not a commit
Segmentation fault (core dumped)
Looking at your patch: is it possible that S_ISDIR() is true for gitlinks as
well as S_ISGITLINK()? S_ISDIR() is from unistd.h; and is presumably
something like:
S_ISDIR() { return mode & S_IFDIR; }
Given the GITLINK mode is S_IFLINK | S_IFDIR; then S_ISDIR() will be true and
if (S_ISDIR(entry.mode))
process_tree(lookup_tree(entry.sha1), p, &me, entry.path);
+ else if (S_ISGITLINK(entry.mode))
+ process_gitlink(entry.sha1, p, &me, entry.path);
else
process_blob(lookup_blob(entry.sha1), p, &me, entry.path);
will never get to the process_gitlink() call.
However; I tried fixing this by swapping the order of the tests and the
problem hasn't gone away. I'm not sure that it's even getting as far as
process_tree(). (incidentally I think the same fault exists in
list-objects.c's process_tree).
Given the hints you gave me in your previous reply, I've looked at the
backtrace again and understood more what's happening.
- mark_reachable_objects() calls add_cache_refs()
- which uses lookup_blob() to mark every hash in the index as an OBJ_BLOB
type of hash; including the GITLINK entries.
- mark_reachable_objects() calls add_one_ref() for_each_ref(), which finds
a ref pointing to one of the GITLINK entries, and via
parse_object_buffer(), tries to lookup_commit(), which finds the GITLINKed
object using lookup_object() only it is not an OBJ_COMMIT, it's an OBJ_BLOB
- all hell breaks loose
I think the fault is in add_cache_refs() which assumes that every hash in the
index is an OBJ_BLOB. I think that add_cache_refs() shouldn't be calling
lookup_blob() for S_ISGITLINK() index entries. Therefore I think this patch
is the right one; what do you reckon?
diff --git a/reachable.c b/reachable.c
index ff3dd34..ffc8d0a 100644
--- a/reachable.c
+++ b/reachable.c
@@ -21,6 +21,15 @@ static void process_blob(struct blob *blob,
/* Nothing to do, really .. The blob lookup was the important part */
}
+static void process_gitlink(const unsigned char *sha1,
+ struct object_array *p,
+ struct name_path *path,
+ const char *name)
+{
+ /* I don't think we want to recurse into this, really. */
+}
+
+
static void process_tree(struct tree *tree,
struct object_array *p,
struct name_path *path,
@@ -45,7 +54,9 @@ static void process_tree(struct tree *tree,
init_tree_desc(&desc, tree->buffer, tree->size);
while (tree_entry(&desc, &entry)) {
- if (S_ISDIR(entry.mode))
+ if (S_ISGITLINK(entry.mode))
+ process_gitlink(entry.sha1, p, &me, entry.path);
+ else if (S_ISDIR(entry.mode))
process_tree(lookup_tree(entry.sha1), p, &me, entry.path);
else
process_blob(lookup_blob(entry.sha1), p, &me, entry.path);
@@ -159,6 +170,16 @@ static void add_cache_refs(struct rev_info *revs)
read_cache();
for (i = 0; i < active_nr; i++) {
+ /*
+ * The index can contain blobs and GITLINKs, GITLINKs are hashes
+ * that don't actually point to objects in the repository, it's
+ * almost guaranteed that they are NOT blobs, so we don't call
+ * lookup_blob() on them, to avoid populating the hash table
+ * with invalid information
+ */
+ if (S_ISGITLINK(ntohl(active_cache[i]->ce_mode)))
+ continue;
+
lookup_blob(active_cache[i]->sha1);
/*
* We could add the blobs to the pending list, but quite
If you think I'm on the right lines with this, I'll make better patches for
Junio.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply related
* Re: [PATCH] Document git-stash
From: Johannes Schindelin @ 2007-07-02 10:33 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano,
しらいしななこ, GIT
In-Reply-To: <20070702041046.GB17384@coredump.intra.peff.net>
Hi,
On Mon, 2 Jul 2007, Jeff King wrote:
> On Sun, Jul 01, 2007 at 02:54:00PM -0700, Junio C Hamano wrote:
>
> > I would further suggest that we _require_ 'git stash save' to create a
> > new one and perhaps make the non-subcommand case run 'git stash list'.
> > While I was trying the code out I accidentally created a new stash
> > when I did not mean to, which pushed the stash I wanted to apply down
> > in the list every time I made such a mistake.
>
> I think that makes sense...it's somehow cleaner to me if the
> non-subcommand case doesn't make any changes (maybe just because I like
> to explore commands by running them).
I disagree entirely.
The _only_ default subcommand for git-stash, which makes _any_ sense, is
"save". I have run my own version of it several times, and it _literally_
was in those circumstances "hack, hack, hack, aargh, stash that, I'll need
it later". "git cherry-pick stash" and "git reflog show stash" were needed
far less.
I am utterly uninterested in the stash list.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-stash: Make "save" the default operation again
From: Johannes Schindelin @ 2007-07-02 10:44 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano,
しらいしななこ, GIT
In-Reply-To: <Pine.LNX.4.64.0707021129540.4438@racer.site>
The default operation really should be that which you are most likely
to use. And that _is_ to stash the current changes away. Indeed, quite
often you will want it to stash away changes you never plan to commit,
like extensive debugging output.
Sometimes you will stash away changes that you realize only later will
never be needed.
So, neither "list" nor "apply" are ase often used in practice as "save".
The manpage already reflects that, so change the script to the better.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Think about it again. You tested git-stash. That is not the normal
modus operandi. You needed to inspect the stashed changes. In the
examples given in the manpage, you usually want to work with the
last stashed changes, if at all. So you _rarely_ inspect the
stashed changes. From my experience I agree.
If you make "list" the default, people will get used to _that_,
even if it means more typing, and quite a few "Aargh, I just
wanted to stash the current state, and I get a list instead!"
moments.
Then there is no way to change it back to some sane default
operation.
git-stash.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index ec18ef6..04ce30a 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -132,7 +132,7 @@ apply_stash () {
# Main command set
case "$1" in
-list | '')
+list)
shift
if test $# = 0
then
@@ -152,7 +152,7 @@ apply)
clear)
clear_stash
;;
-save)
+save|'')
save_stash && git-reset --hard
;;
*)
--
1.5.2.2.3293.gad30
^ permalink raw reply related
* Re: [PATCH] git-stash: Make "save" the default operation again
From: Jeff King @ 2007-07-02 11:00 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano,
しらいしななこ, GIT
In-Reply-To: <Pine.LNX.4.64.0707021141280.4438@racer.site>
On Mon, Jul 02, 2007 at 11:44:29AM +0100, Johannes Schindelin wrote:
> So, neither "list" nor "apply" are ase often used in practice as "save".
> The manpage already reflects that, so change the script to the better.
I have to admit that I don't really care all that much, so I'll let you
guys duke it out.
-Peff
^ permalink raw reply
* [PATCH] Teach git-stash to "apply --index"
From: Johannes Schindelin @ 2007-07-02 11:14 UTC (permalink / raw)
To: git, gitster
When given this subcommand, git-stash will try to merge the stashed
index into the current one. Only trivial merges are possible, since
we have no index for the index ;-) If a trivial merge is not possible,
git-stash will bail out with a hint to skip the --index option.
For good measure, finally include a test case.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I am not quite sure if this should not be the default, with
--skip-index to turn it off if the trivial index merge fails,
and the user might be interested only in the working directory
changes anyway.
Comments?
git-stash.sh | 21 ++++++++++++++++
t/t3903-stash.sh | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 89 insertions(+), 1 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 04ce30a..45ad2f4 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -98,6 +98,13 @@ apply_stash () {
git-diff-files --quiet ||
die 'Cannot restore on top of a dirty state'
+ unstash_index=
+ case "$1" in
+ --index)
+ unstash_index=t
+ shift
+ esac
+
# current index state
c_tree=$(git-write-tree) ||
die 'Cannot apply a stash in the middle of a merge'
@@ -107,6 +114,15 @@ apply_stash () {
b_tree=$(git-rev-parse --verify "$s^:") ||
die "$*: no valid stashed state found"
+ test -z "$unstash_index" || {
+ git diff --binary $s^2^..$s^2 | git apply --cached
+ test $? -ne 0 &&
+ die 'Conflicts in index. Try without --index.'
+ unstashed_index_tree=$(git-write-tree) ||
+ die 'Could not save index tree'
+ git reset
+ }
+
eval "
GITHEAD_$w_tree='Stashed changes' &&
GITHEAD_$c_tree='Updated upstream' &&
@@ -124,9 +140,12 @@ apply_stash () {
die "Cannot unstage modified files"
git-status
rm -f "$a"
+ test -z "$unstash_index" || git read-tree $unstashed_index_tree
else
# Merge conflict; keep the exit status from merge-recursive
- exit
+ status=$?
+ test -z "$unstash_index" || echo 'Index was not unstashed.' >&2
+ exit $status
fi
}
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
new file mode 100755
index 0000000..392ac1c
--- /dev/null
+++ b/t/t3903-stash.sh
@@ -0,0 +1,69 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E Schindelin
+#
+
+test_description='Test git-stash'
+
+. ./test-lib.sh
+
+test_expect_success 'stash some dirty working directory' '
+ echo 1 > file &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+ echo 2 > file &&
+ git add file &&
+ echo 3 > file &&
+ test_tick &&
+ git stash &&
+ git diff-files --quiet &&
+ git diff-index --cached --quiet HEAD
+'
+
+cat > expect << EOF
+diff --git a/file b/file
+index 0cfbf08..00750ed 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-2
++3
+EOF
+
+test_expect_success 'parents of stash' '
+ test $(git rev-parse stash^) = $(git rev-parse HEAD) &&
+ git diff stash^2..stash > output &&
+ diff -u output expect
+'
+
+test_expect_success 'apply needs clean working directory' '
+ echo 4 > other-file &&
+ git add other-file &&
+ echo 5 > other-file
+ ! git stash apply
+'
+
+test_expect_success 'apply stashed changes' '
+ git add other-file &&
+ test_tick &&
+ git commit -m other-file &&
+ git stash apply &&
+ test 3 = $(cat file) &&
+ test 1 = $(git show :file) &&
+ test 1 = $(git show HEAD:file)
+'
+
+test_expect_success 'apply stashed changes (including index)' '
+ git reset --hard HEAD^ &&
+ echo 6 > other-file &&
+ git add other-file &&
+ test_tick &&
+ git commit -m other-file &&
+ git stash apply --index &&
+ test 3 = $(cat file) &&
+ test 2 = $(git show :file) &&
+ test 1 = $(git show HEAD:file)
+'
+
+test_done
^ permalink raw reply related
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