* Re: [PATCH] rebase -p: seed first commit in case it's before the merge bases.
From: Stephen Haberman @ 2009-01-18 3:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Michael J Gruber, Stephan Beyer, Sitaram Chamarty
In-Reply-To: <alpine.DEB.1.00.0901180108480.3586@pacific.mpi-cbg.de>
> > However, I have a strong feeling that just piling onto the current
> > code will not fix the underlying issues.
>
> BTW just to clarify what I mean by "underlying issues": if you say
> "git rebase -i" in Sitaram's test case, you will see the two commits
> -- as expected.
>
> However, if you add "-p", all of a sudden you will only see "noop".
> IMO there is no excuse that the code can hide them at all. If the
> commits are reachable from HEAD but not from $UPSTREAM, they have to
> be in the list. As simple as that.
Agreed--the rewritten-parent probing being rooted at the merge bases
was not good enough.
> Another thing that I find horribly wrong: there is a "touch
> $REWRITTEN/sha1". There was a simple design in the beginning: the
> files in $REWRITTEN are actually a mapping from old SHA-1 (file name)
> to new SHA-1 (content). This was broken, without any good
> explanation.
Perhaps it is not "good", but the explanation a blank REWRITTEN/sha1 is
used a marker during the probe phase that this commit will be rewritten.
So when looking at any of its children commits, they should be rewritten
if a REWRITTEN/parentSha1 exists. Then as the rewriting actually happens,
they get filled in with the new sha1. I cribbed this approach from
Stephan's sequencer rewrite of rebase-i-p.
If you want a different data structure, be it file based, or bash/list
based, or whatever, to track "this commit will eventually be rewritten
but we haven't gotten there yet" during the probe, then we could go back
to leaving REWRITTEN/sha1 alone until after the sha1 commit has been
rebased.
I'm open to suggestions.
Also, as you seem to realize, the current bug stems from not knowing how
to initialize the rewritten data structure. For Sitaram's case, the
first commit is behind any of the merge bases, so marking its parents
(if they exist) as rewritten to ONTO seems reasonable.
If there are no parents, as you point out, I added a "-o sha1 = FIRST"
that should also get the ball rolling. It's another hack, but does this
address your concern until a large refactoring happens?
-------------------------- git-rebase--interactive.sh --------------------------
index c8b0861..8740d9f 100755
@@ -604,11 +604,18 @@ first and then run 'git rebase --continue' again."
echo $ONTO > "$REWRITTEN"/$c ||
die "Could not init rewritten commits"
done
+ # Along with the merge bases, look at the first commit's
+ # parent (which may be before the merge base) and mark it
+ # as rewritten to ONTO
+ FIRST="$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)"
+ for p in $(git rev-list --parents -1 $FIRST | cut -d' ' -f2)
+ do
+ echo $ONTO > "$REWRITTEN/$p"
+ done
# No cherry-pick because our first pass is to determine
# parents to rewrite and skipping dropped commits would
# prematurely end our probe
MERGES_OPTION=
- first_after_upstream="$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)"
else
MERGES_OPTION="--no-merges --cherry-pick"
fi
@@ -629,12 +636,12 @@ first and then run 'git rebase --continue' again."
preserve=t
for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -f2-)
do
- if test -f "$REWRITTEN"/$p -a \( $p != $UPSTREAM -o $sha1 = $first_after_upstream \)
+ if test -f "$REWRITTEN"/$p -a $p != $UPSTREAM
then
preserve=f
fi
done
- if test f = "$preserve"
+ if test f = "$preserve" -o $sha1 = $FIRST
then
touch "$REWRITTEN"/$sha1
echo "pick $shortsha1 $rest" >> "$TODO"
(I'm adding the other 3 cc's back after my failed patch attempt
stripped them out--sorry, guys.)
- Stephen
^ permalink raw reply
* Re: [PATCH 2/2] http-push: remove MOVE step after PUT when sending objects to server
From: Ray Chuan @ 2009-01-18 3:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqod5thi.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, Jan 18, 2009 at 12:48 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Ray Chuan" <rctay89@gmail.com> writes:
>
>> Currently, git PUTs to
>>
>> /repo.git/objects/1a/1a2b...9z_opaquelocktoken:1234-....
>>
>> then MOVEs to
>>
>> /repo.git/objects/1a/1a2b...9z
>>
>> This is needless. In fact, the only time MOVE requests are sent is for
>> this sole purpose (ie. of renaming an object).
this would be my "true" reason. i do believe PUTting to a "temporary"
file (ie with '__opaquelocktoken:1234-....' appended) to be a needless
step.
>> A concern raised was repository corruption in the event of failure
>> during PUT. "put && move" won't afford any more protection than using
>> simply "put", since info/refs is not updated if a PUT fails, so there
>> is no cause for concern.
>
> That's a completely bogus reasoning. Normal operation inside the
> repository that was pushed into won't look at info/refs at all.
>
> The true reason you want to avoid put-then-move is...?
i mentioned this "repository corruption" issue as it was raised
previously by Johannes (towards the bottom):
http://article.gmane.org/gmane.comp.version-control.git/106031
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Thomas Rast @ 2009-01-18 2:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vvdsd1hur.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > I came up with this after sending two incomplete patches on the same
> > night, and really like it. Perhaps others might find it useful.
>
> Any patch worth discussing (on this list at least) would need a nontrivial
> commit log message that you need to really think while writing. It is
> natural to assume people would be making them with their editor, not with
> "commit -m". These two incomplete patches could have been avoided if you
> paid attention to the status output that is in the commit log message
> buffer. Perhaps we should make it even louder in some way?
Actually I tend to write the commit (and message) sometime halfway
through, and then amend the commit with fixes, docs and such, possibly
tweaking the message if I need to. That night I just forgot to amend
before format-patch, and there's no status message at that point which
could have reminded me. So the *+ display is just what I needed; it
shows the status right before I get a chance to format-patch (or
whatever else command expects a commit).
[As a side note, this kind of workflow is what will probably prevent
me from working with any other SCM in the near future. I simply
cannot imagine going back to a world without add -p, commit --amend
and rebase -i.]
That being said, I never look at that status message; so far I've been
too lazy to make my emacs add syntax highlighting there, and without
it, it's just a big chunk of text. In fact, for most commits the 1-2
file names completely drown in the big chunk of surrounding,
invariant, instructions. If it becomes even louder in the ASCII
dimension, that most likely means I'll just have to steer my eye away
from it even harder to see the commit message I'm typing. Perhaps
some colours would help, I should really try that.
Of course the real solution would be to hack less and sleep more, but
who would want to do that?
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Junio C Hamano @ 2009-01-18 2:13 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Shawn O. Pearce
In-Reply-To: <1232240184-10906-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> I came up with this after sending two incomplete patches on the same
> night, and really like it. Perhaps others might find it useful.
Any patch worth discussing (on this list at least) would need a nontrivial
commit log message that you need to really think while writing. It is
natural to assume people would be making them with their editor, not with
"commit -m". These two incomplete patches could have been avoided if you
paid attention to the status output that is in the commit log message
buffer. Perhaps we should make it even louder in some way?
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Thomas Rast @ 2009-01-18 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vwsct2xd1.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 716 bytes --]
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > + if test ! -z "$GIT_PS1_EXPENSIVE"; then
> > + git update-index --refresh >/dev/null 2>&1 || w="*"
>
> This makes the feature unavailable for people who care about the stat
> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?
True, and I admit I didn't know there was an option to change that.
OTOH git-diff-files doesn't normally update the index even if the
option is set. Should I ask 'git diff --exit-code --raw' or some such
instead?
(Why would people want to keep the stat info dirty even though there
may not have been any changes?)
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] checkout: don't crash on file checkout before running post-checkout hook
From: Stephan Beyer @ 2009-01-18 2:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Paolo Bonzini, Miklos Vajna,
Shawn O. Pearce, Daniel Barkalow, Christian Couder
In-Reply-To: <7vd4el2x7g.fsf@gitster.siamese.dyndns.org>
Hi,
Junio C Hamano wrote:
> All looked good to me except one thing; you need to initialize argv to
> NULL as ALLOC_GROW() calls xrealloc on it in the last one.
This is true. Sorry.
> Will queue with an amend.
Thank you.
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH v2 1/5] checkout: don't crash on file checkout before running post-checkout hook
From: Junio C Hamano @ 2009-01-18 1:56 UTC (permalink / raw)
To: Stephan Beyer
Cc: git, Johannes Schindelin, Paolo Bonzini, Miklos Vajna,
Shawn O. Pearce, Daniel Barkalow, Christian Couder, gitster
In-Reply-To: <1232133002-21725-1-git-send-email-s-beyer@gmx.net>
All looked good to me except one thing; you need to initialize argv to
NULL as ALLOC_GROW() calls xrealloc on it in the last one.
Will queue with an amend.
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Junio C Hamano @ 2009-01-18 1:53 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Shawn O. Pearce
In-Reply-To: <1232240184-10906-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> + if test ! -z "$GIT_PS1_EXPENSIVE"; then
> + git update-index --refresh >/dev/null 2>&1 || w="*"
This makes the feature unavailable for people who care about the stat
dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?
^ permalink raw reply
* [TOY PATCH] git-resurrect: find traces of a branch name and resurrect it
From: Thomas Rast @ 2009-01-18 1:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901161213370.3586@pacific.mpi-cbg.de>
Add a tool 'git resurrect <branch>...' that tries to find traces of
each <branch> in the HEAD reflog and, optionally, all merge commits in
the repository. It can then resurrect the branch, pointing it at the
most recent of all candidate commits found.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
So here's a slightly more polished version so gmane can keep it
forever. Thanks for the sed trick! I was too lazy to add more
options, but at least there's a "fast" and a "complete" mode.
Makefile | 1 +
git-resurrect.sh | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 110 insertions(+), 0 deletions(-)
create mode 100755 git-resurrect.sh
diff --git a/Makefile b/Makefile
index 2b873fa..87cb539 100644
--- a/Makefile
+++ b/Makefile
@@ -260,6 +260,7 @@ SCRIPT_SH += git-merge-resolve.sh
SCRIPT_SH += git-mergetool.sh
SCRIPT_SH += git-parse-remote.sh
SCRIPT_SH += git-pull.sh
+SCRIPT_SH += git-resurrect.sh
SCRIPT_SH += git-quiltimport.sh
SCRIPT_SH += git-rebase--interactive.sh
SCRIPT_SH += git-rebase.sh
diff --git a/git-resurrect.sh b/git-resurrect.sh
new file mode 100755
index 0000000..6d5a0c7
--- /dev/null
+++ b/git-resurrect.sh
@@ -0,0 +1,109 @@
+#!/bin/sh
+
+USAGE="git resurrect [-m | --merges] [-n | --dry-run] <name>..."
+LONG_USAGE="git-resurrect attempts to find traces of a branch tip called <name>,
+and tries to resurrect it. Currently, the reflog is searched for
+checkout and merge messages. With --merges, the history of all refs
+is scanned for merge commit subjects, which is rather slow but allows
+you to resurrect other people's topic branches."
+
+. git-sh-setup
+cd_to_toplevel
+
+OPTIONS_SPEC="\
+git resurrect [-m | --merges] [-n | --dry-run] <name>...
+--
+m,merges also scan merges (slow)
+n,dry-run don't recreate the branch"
+
+test "$#" = 0 && usage
+
+eval "$(echo "$OPTIONS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
+
+search_reflog () {
+ sed -n 's~^\([^ ]*\) .*\tcheckout: moving from '"$1"' .*~\1~p' \
+ < .git/logs/HEAD
+}
+
+search_reflog_merges () {
+ sed -n 's~^[^ ]* \([^ ]*\) .*\tmerge '"$1"':~\1~p' \
+ < .git/logs/HEAD
+}
+
+search_merges () {
+ git rev-list --pretty=tformat:"%h %p:%s" --all |
+ grep "Merge branch.*'$branch'.*into" |
+ while read sha rest; do
+ parents="$(echo "$rest" | cut -d: -f1)"
+ case "$parents" in
+ *' '*' '*)
+ warn "$branch took part in octopus merge $sha"
+ warn "check manually!"
+ ;;
+ *' '*)
+ echo "$parents" | cut -d' ' -f2
+ ;;
+ esac
+ done
+}
+
+search_merge_targets () {
+ git rev-list --pretty=tformat:"%h %s" --all |
+ grep "Merge branch '[^']*' into $branch$" |
+ cut -d' ' -f1
+}
+
+dry_run=
+scan_merges=
+
+while test "$#" != 0; do
+ case "$1" in
+ -n|--dry-run)
+ dry_run=t
+ ;;
+ -m|--merges)
+ scan_merges=t
+ ;;
+ --)
+ shift
+ break
+ ;;
+ *)
+ usage
+ ;;
+ esac
+ shift
+done
+
+for branch in "$@"; do
+ candidates="$(search_reflog $1; search_reflog_merges $1)"
+ if test ! -z "$scan_merges"; then
+ candidates="$candidates $(search_merges $1; search_merge_targets $1)"
+ fi
+
+ candidates="$(git rev-parse $candidates | sort -u)"
+
+ if test -z "$candidates"; then
+ echo "** No candidates for $branch found **"
+ test -z "$scan_merges" && echo "(maybe try again with -m)"
+ else
+ echo "** Candidates for $branch **"
+ for cmt in $candidates; do
+ git --no-pager log --pretty=oneline --abbrev-commit -1 $cmt
+ done
+
+ newest="$(git rev-list -1 $candidates)"
+ if test ! -z "$dry_run"; then
+ printf "Most recent: "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+ elif ! git rev-parse --verify --quiet $branch >/dev/null; then
+ printf "** Restoring $branch to "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+ git branch $branch $newest
+ else
+ printf "Most recent: "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+ echo "** $branch already exists, doing nothing"
+ fi
+ fi
+done
--
1.6.1.320.gd5dca.dirty
^ permalink raw reply related
* Re: [PATCH] mergetool: put the cursor on the editable file for Vim
From: Junio C Hamano @ 2009-01-18 1:35 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200901172228.45450.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> When resolving conflicts, you only need to edit the $MERGED file. Put
> the cursor automatically into its window for vimdiff and gvimdiff to
> avoid doing <C-w>l every time.
I think this is sensible.
I do not use vim, and I do not know if the patch does what it claims to
do, though.
^ permalink raw reply
* Re: [PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository
From: Junio C Hamano @ 2009-01-18 1:31 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git, gitster
In-Reply-To: <1232208943-31756-1-git-send-email-dato@net.com.org.es>
Adeodato Simó <dato@net.com.org.es> writes:
> If logs/refs or rr-cache are dangling symlinks in the workdir, and reflogs
> and/or rerere are enabled, commit will die with "fatal: Could not create
> directory". (In the case of rr-cache, it will die after having created the
> commit.)
>
> This commit just creates logs/refs and rr-cache in the origin repository if
> they don't exist already.
Hmm, is that better than not creating the symlink of the borrowed
repository does not have them?
^ permalink raw reply
* Re: [PATCH] git svn clone -s was not prefixing 'branches/'
From: Eric Wong @ 2009-01-18 1:24 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Jon Lim, git
In-Reply-To: <20090117120723.GA24549@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2009.01.17 11:39:28 +0000, Jon Lim wrote:
> > Hi,
> >
> > Maybe this patch doesn't fix the problem I was having. I will attempt
> > to describe it better here.
> >
> > I understand that a standard subversion setup is as follows:
> > trunk
> > branches
> > tags
> >
> > With the -s option, svn clone should expect this.
> >
> > Using the example subversion repository:
> > trunk
> > branches/RB_1.0
> > branches/RB_2.0
> > tags/REL_1.0
> > tags/REL_2.0
> >
> > Currently, using the -s option you get:
> > trunk
> > RB_1.0
> > RB_2.0
> > tags/REL_1.0
> > tags/REL_2.0
> >
> > I think it makes sense to have:
> > trunk
> > branches/RB_1.0
> > branches/RB_2.0
> > tags/REL_1.0
> > tags/REL_2.0
>
> Why? "trunk" is just a branch like any other branch, too. It's basically
> just a svn convention that it's not in branches/ but in its own
> "toplevel" directory. Once imported into git, it's just an ordinary
> remote tracking branch. It's already pretty well distiguishable from all
> the other branches due to its name.
Yup, you said it better than I could myself :)
> What _does_ make sense is to have a common prefix for all the stuff you
> got from svn, using for example --prefix=svn/. That way you get:
> svn/trunk
> svn/RB_1.0
> svn/RB_2.0
> svn/tags/REL_1.0
> svn/tags/REL_2.0
>
> The important part is that those names aren't ambiguous if you have
> local branch heads called, for example:
> trunk
> RB_1.0
> RB_2.0
>
> as the svn/ prefix is part of the shortname for the remote tracking
> branches. So "trunk" is the branch head and "svn/trunk" is the remote
> tracking branch.
>
> Btw Eric, is there any reason why there's no prefix used by default?
> Using the name for the svn-remote as the prefix would make a lot of
> sense to me.
Backwards compatibility; and that I've been lazy :)
But I do agree that prefixing "svn/" is preferred for tracking new
repos. I seem to recall that git-svn was actually the first user of the
"remotes/" namespace before it was adopted by the rest of git, and with
SVN, I didn't anticipate more than one remote.
--
Eric Wong
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Anders Melchiorsen @ 2009-01-18 1:24 UTC (permalink / raw)
To: Björn Steinbrink
Cc: SZEDER Gábor, Sverre Rabbelier, Junio C Hamano, git,
Johannes.Schindelin
In-Reply-To: <20090116001139.GA26357@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> No, you don't have to do that. As long as you only want to "edit"
> the commit you marked as "edit", you only need to use "git add" and
> "git rebase --continue". rebase -i checks whether HEAD still
> resolves to the same commit and if so, it automatically does the
> soft reset for you.
>
> Maybe we should just advertise that in the message provided by
> rebase after it stops? I'm afraid I can't come up with a sane
> wording though, as there are still cases when you need to commit
> yourself, eg. when you use reset. And getting that into one simple
> sentence seems a bit hard (for me).
I was happy to learn that trick when looking at the source, so I agree
that it is a good idea to advertise it. You are right that it is hard
to describe well in few words, though. Does somebody feel like
repainting this?
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -336,14 +336,13 @@ do_next () {
make_patch $sha1
git rev-parse --verify HEAD > "$DOTEST"/amend
warn "Stopped at $sha1... $rest"
- warn "You can amend the commit now, with"
- warn
- warn " git commit --amend"
- warn
- warn "Once you are satisfied with your changes, run"
+ warn "You can amend the commit now, by marking"
+ warn "paths with 'git add <paths>' and running"
warn
warn " git rebase --continue"
warn
+ warn "If you want to create new commits, run"
+ warn "'git commit' yourself before continuing."
exit 0
;;
squash|s)
^ permalink raw reply
* Re: [PATCH] interpret_nth_last_branch(): avoid traversing the reflogs twice
From: Johannes Schindelin @ 2009-01-18 1:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vmydp5tqj.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 17 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > That is correct. But this is such a highly uncritical code path that
> > I'd like to keep this simple rather than fast.
>
> I actually not worried about "fast" at all; it was more about unbounded
> memory consumption.
Let's just assume that I make a branch switch per minute, continuously,
for 90 days (until the reflogs are expired), and let's say that all my
branchnames have 20 characters. Conservatively, the memory requirement
would be 100 * 2000 * 30 = 3 megabyte.
Note: these are the memory requirements after some really unrealistically
high activity, and the memory is free()d during parameter parsing.
A much more realistical expectation would be to switch branches maybe 20
times a day, which would amount to something like 36 kilobyte. And again,
they are free()d before the action really starts.
Ciao,
Dscho
^ permalink raw reply
* [PATCH next resend] bash completion: refactor diff options
From: Thomas Rast @ 2009-01-18 1:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1231679663-31907-1-git-send-email-trast@student.ethz.ch>
diff, log and show all take the same diff options. Refactor them from
__git_diff and __git_log into a variable, and complete them in
__git_show too.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Any news on this?
contrib/completion/git-completion.bash | 38 ++++++++++++++++++-------------
1 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 70a6b44..40e3a14 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -774,25 +774,30 @@ _git_describe ()
__gitcomp "$(__git_refs)"
}
-_git_diff ()
-{
- __git_has_doubledash && return
-
- local cur="${COMP_WORDS[COMP_CWORD]}"
- case "$cur" in
- --*)
- __gitcomp "--cached --stat --numstat --shortstat --summary
+__git_diff_common_options="--stat --numstat --shortstat --summary
--patch-with-stat --name-only --name-status --color
--no-color --color-words --no-renames --check
--full-index --binary --abbrev --diff-filter=
- --find-copies-harder --pickaxe-all --pickaxe-regex
+ --find-copies-harder
--text --ignore-space-at-eol --ignore-space-change
--ignore-all-space --exit-code --quiet --ext-diff
--no-ext-diff
--no-prefix --src-prefix= --dst-prefix=
- --base --ours --theirs
--inter-hunk-context=
--patience
+ --raw
+"
+
+_git_diff ()
+{
+ __git_has_doubledash && return
+
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--cached --pickaxe-all --pickaxe-regex
+ --base --ours --theirs
+ $__git_diff_common_options
"
return
;;
@@ -975,17 +980,16 @@ _git_log ()
--relative-date --date=
--author= --committer= --grep=
--all-match
- --pretty= --name-status --name-only --raw
+ --pretty=
--not --all
--left-right --cherry-pick
--graph
- --stat --numstat --shortstat
- --decorate --diff-filter=
- --color-words --walk-reflogs
+ --decorate
+ --walk-reflogs
--parents --children --full-history
--merge
--inter-hunk-context=
- --patience
+ $__git_diff_common_options
"
return
;;
@@ -1490,7 +1494,9 @@ _git_show ()
return
;;
--*)
- __gitcomp "--pretty="
+ __gitcomp "--pretty=
+ $__git_diff_common_options
+ "
return
;;
esac
--
tg: (7ff1443..) t/bash-complete-show (depends on: origin/next)
^ permalink raw reply related
* [PATCH] bash: offer to show (un)staged changes
From: Thomas Rast @ 2009-01-18 0:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce
Add a bit of code to __git_ps1 that lets it append '*' to the branch
name if there are any uncommitted changes, and '+' if there are any
staged changes.
Since this is a rather expensive operation and will force a lot of
data into the cache whenever you first enter a repository, you have to
enable it manually by setting GIT_PS1_EXPENSIVE to something nonempty.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I came up with this after sending two incomplete patches on the same
night, and really like it. Perhaps others might find it useful.
Of course it would be brilliant if there were a way to ask the kernel
if a certain directory is cached, but I couldn't find one, let alone
one accessible from the shell.
contrib/completion/git-completion.bash | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index f8b845a..36ea528 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -34,6 +34,10 @@
# are currently in a git repository. The %s token will be
# the name of the current branch.
#
+# In addition, if you set GIT_PS1_EXPENSIVE to a nonempty value,
+# unstaged (*) and staged (+) changes will be shown next to the
+# branch name.
+#
# To submit patches:
#
# *) Read Documentation/SubmittingPatches
@@ -116,10 +120,23 @@ __git_ps1 ()
fi
fi
+ local w
+ local i
+
+ if test ! -z "$GIT_PS1_EXPENSIVE"; then
+ git update-index --refresh >/dev/null 2>&1 || w="*"
+ if git rev-parse --quiet --verify HEAD >/dev/null; then
+ git diff-index --cached --quiet \
+ --ignore-submodules HEAD -- || i="+"
+ else
+ i="#"
+ fi
+ fi
+
if [ -n "${1-}" ]; then
- printf "$1" "${b##refs/heads/}$r"
+ printf "$1" "${b##refs/heads/}$w$i$r"
else
- printf " (%s)" "${b##refs/heads/}$r"
+ printf " (%s)" "${b##refs/heads/}$w$i$r"
fi
fi
}
--
tg: (7bbd8d6..) t/ps1-dirty-state (depends on: origin/master)
^ permalink raw reply related
* Re: [PATCH/RFC v4 2/5] sha1_name: tweak @{-N} lookup
From: Junio C Hamano @ 2009-01-18 0:54 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Johannes Schindelin, Johannes Sixt, Johan Herland
In-Reply-To: <1232208597-29249-3-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Have the lookup only look at "interesting" checkouts, meaning those
> that tell you "Already on ..." don't count even though they also cause
> a reflog entry.
>
> Let interpret_nth_last_branch() return the number of characters
> parsed, so that git-checkout can verify that the branch spec was
> @{-N}, not @{-1}^2 or something like that. (The latter will be added
> later.)
Thanks; you seem to have handled the issues I pointed out in response to
my own weatherbaloon patch. I think it is probably better to squash the
first two (and you take the authorship).
> diff --git a/sha1_name.c b/sha1_name.c
> index 6377264..34e39db 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -685,29 +685,28 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
> const char *message, void *cb_data)
> {
> struct grab_nth_branch_switch_cbdata *cb = cb_data;
> - const char *match = NULL;
> -
> - if (!prefixcmp(message, "checkout: moving to "))
> - match = message + strlen("checkout: moving to ");
> - else if (!prefixcmp(message, "checkout: moving from ")) {
> - const char *cp = message + strlen("checkout: moving from ");
> - if ((cp = strstr(cp, " to ")) != NULL) {
> - match = cp + 4;
> - }
> + const char *match = NULL, *target = NULL;
> + size_t len;
> +
> + if (!prefixcmp(message, "checkout: moving from ")) {
> + match = message + strlen("checkout: moving from ");
> + if ((target = strstr(match, " to ")) != NULL)
> + target += 4;
> }
This drops support for older reflog records, but I think it would be Ok.
This "N-th" support is really meant to be for small number of N anyway.
> - if (--cb->nth <= 0) {
> - size_t len = strlen(match);
> - while (match[len-1] == '\n')
> - len--;
> + if (cb->nth-- <= 0) {
> strbuf_reset(cb->buf);
> strbuf_add(cb->buf, match, len);
> return 1;
Hmm, did I have an off-by-one I did not notice? ;-)
> int interpret_nth_last_branch(const char *name, struct strbuf *buf)
> {
> - int nth, i;
> + int nth;
> struct grab_nth_branch_switch_cbdata cb;
> + const char *brace;
> + char *num_end;
>
> if (name[0] != '@' || name[1] != '{' || name[2] != '-')
> return -1;
> - for (i = 3, nth = 0; name[i] && name[i] != '}'; i++) {
> - char ch = name[i];
> - if ('0' <= ch && ch <= '9')
> - nth = nth * 10 + ch - '0';
> - else
> - return -1;
> - }
> - if (nth < 0 || 10 <= nth)
The removal of "limit to reasonably small recent N" I somewhat have
reservations on, but I think we can later re-add something based on
configuration variable if we need to.
^ permalink raw reply
* Re: log-tree.c: date hardwired
From: Junio C Hamano @ 2009-01-18 0:52 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87fxjhcy3i.fsf@jidanni.org>
jidanni@jidanni.org writes:
> Can I get a go-ahead from somebody for me to begin work on implementing a fix?
No, don't "fix" it.
Please keep it as a known constant. That way, you can come up with an
/etc/magic entry to teach find(1) that it is not just a random mailbox but
is an output from format-patch.
^ permalink raw reply
* Re: [PATCH 2/2] http-push: remove MOVE step after PUT when sending objects to server
From: Junio C Hamano @ 2009-01-18 0:48 UTC (permalink / raw)
To: Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0901171224y35c3d95cn2d38639ac03c3b8f@mail.gmail.com>
"Ray Chuan" <rctay89@gmail.com> writes:
> Currently, git PUTs to
>
> /repo.git/objects/1a/1a2b...9z_opaquelocktoken:1234-....
>
> then MOVEs to
>
> /repo.git/objects/1a/1a2b...9z
>
> This is needless. In fact, the only time MOVE requests are sent is for
> this sole purpose (ie. of renaming an object).
>
> A concern raised was repository corruption in the event of failure
> during PUT. "put && move" won't afford any more protection than using
> simply "put", since info/refs is not updated if a PUT fails, so there
> is no cause for concern.
That's a completely bogus reasoning. Normal operation inside the
repository that was pushed into won't look at info/refs at all.
The true reason you want to avoid put-then-move is...?
^ permalink raw reply
* Re: [PATCH] interpret_nth_last_branch(): avoid traversing the reflogs twice
From: Junio C Hamano @ 2009-01-18 0:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <alpine.DEB.1.00.0901172028470.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> That is correct. But this is such a highly uncritical code path that I'd
> like to keep this simple rather than fast.
I actually not worried about "fast" at all; it was more about unbounded
memory consumption.
^ permalink raw reply
* Re: log-tree.c: date hardwired
From: Sitaram Chamarty @ 2009-01-18 0:40 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0901171538l5e9fb66bh862c9b7a125fc98f@mail.gmail.com>
On 2009-01-17, Alex Riesen <raa.lkml@gmail.com> wrote:
> 2009/1/18 <jidanni@jidanni.org>:
>> Can I get a go-ahead from somebody for me to begin work
>> on implementing a fix?
>
> No. Try and guess why
OK, I'll bite...
Because it's only used as the date for the mbox format
leader line, and not an actual email (RFC 822/2822) header
line? And in that format it represents "delivery date",
which is irrelevant for stuff you're generating to be sent
out anyway, meaning this line doesn't actually get sent out
to anyone when you mail your patches, so we don't care what
it is.
I can't think of anything else, so if it isn't that please
do tell. Not that I cared about it before, but once someone
says "try and guess why" it somehow becomes important :-)
^ permalink raw reply
* Re: [PATCH] rebase -p: seed first commit in case it's before the merge bases.
From: Johannes Schindelin @ 2009-01-18 0:19 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901180041540.3586@pacific.mpi-cbg.de>
Hi,
On Sun, 18 Jan 2009, Johannes Schindelin wrote:
> However, I have a strong feeling that just piling onto the current code
> will not fix the underlying issues.
BTW just to clarify what I mean by "underlying issues": if you say "git
rebase -i" in Sitaram's test case, you will see the two commits -- as
expected.
However, if you add "-p", all of a sudden you will only see "noop". IMO
there is no excuse that the code can hide them at all. If the commits are
reachable from HEAD but not from $UPSTREAM, they have to be in the list.
As simple as that.
Another thing that I find horribly wrong: there is a "touch
$REWRITTEN/sha1". There was a simple design in the beginning: the files
in $REWRITTEN are actually a mapping from old SHA-1 (file name) to new
SHA-1 (content). This was broken, without any good explanation.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -p: seed first commit in case it's before the merge bases.
From: Stephen Haberman @ 2009-01-18 0:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901180041540.3586@pacific.mpi-cbg.de>
> > + # Along with the merge bases, look at the first commit's
> > + # parent (which may be before the merge base) and mark it
> > + # as rewritten to ONTO
> > + FIRST="$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)"
> > + for p in $(git rev-list --parents -1 $FIRST | cut -d' ' -f2)
> > + do
> > + echo $ONTO > "$REWRITTEN/$p"
> > + done
>
> AFAICT this is wrong. You have no guarantee whatsoever that the output of
>
> $ git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1
>
> has any parents at all. Take for example a coolest-merge-ever, i.e. a
> merge of an independent project.
>
> Instead, what you _actually_ are looking for are the boundary objects
> of $UPSTREAM..$HEAD,
Agreed.
> which would be easy to get at.
That would be great, but I'm not seeing it, obviously. Suggestions
would be appreciated.
> However, I have a strong feeling that just piling onto the current
> code will not fix the underlying issues.
Also agreed.
So...not that it really matters, but did my patches go out to the git
list or not? It looks like both Johannes and I got them from the cc
entries.
I tried to use format-patch and the files looked great, cc's including
Michael, Stephan, and Sitaram. Then I ran send-email with the three
files as arguments and it stripped all the cc's but Johannes and
myself. Then I got all three delivered due to my cc entry, but I didn't
see any entries arrive from the list even though the cc-delivered
copies all had "To: git@vger.kernel.org" in them (and that is what I
had pasted into the send-email prompt). I guess I did something wrong
but it's frustrating to not know what it was.
- Stephen
^ permalink raw reply
* Re: [PATCH] rebase -p: seed first commit in case it's before the merge bases.
From: Johannes Schindelin @ 2009-01-17 23:51 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <a524993b13ee586cf0e8fbd3b6459ccd6767c6d8.1232233454.git.stephen@exigencecorp.com>
Hi,
On Sat, 17 Jan 2009, Stephen Haberman wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index c8b0861..e800e07 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -604,11 +604,18 @@ first and then run 'git rebase --continue' again."
> echo $ONTO > "$REWRITTEN"/$c ||
> die "Could not init rewritten commits"
> done
> + # Along with the merge bases, look at the first commit's
> + # parent (which may be before the merge base) and mark it
> + # as rewritten to ONTO
> + FIRST="$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)"
> + for p in $(git rev-list --parents -1 $FIRST | cut -d' ' -f2)
> + do
> + echo $ONTO > "$REWRITTEN/$p"
> + done
AFAICT this is wrong. You have no guarantee whatsoever that the output of
$ git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1
has any parents at all. Take for example a coolest-merge-ever, i.e. a
merge of an independent project.
Instead, what you _actually_ are looking for are the boundary objects of
$UPSTREAM..$HEAD, which would be easy to get at.
However, I have a strong feeling that just piling onto the current code
will not fix the underlying issues.
Ciao,
Dscho
^ permalink raw reply
* Re: log-tree.c: date hardwired
From: jidanni @ 2009-01-17 23:50 UTC (permalink / raw)
To: raa.lkml; +Cc: git
In-Reply-To: <81b0412b0901171538l5e9fb66bh862c9b7a125fc98f@mail.gmail.com>
Perhaps a comment could be added to the code as to the reason a date
or that certain date is hardwired. Any reason would be satisfactory.
^ 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