* Re: [PATCH] gittutorial: remove misleading note
From: Junio C Hamano @ 2009-01-23 19:00 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1232733749-6120-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> In the tutorial Alice initializes the repository, and Bob clones it. So
> Bob can just do a 'git pull', but Alice will need 'git pull <url>
> <branch>'.
>
> The note suggested that the branch parameter is not necessary, which is
> no longer true these days.
So we have a usability regression here. Perhaps we need to fix that
instead?
^ permalink raw reply
* Re: git blame: two "-C"s versus just a single -C
From: Sitaram Chamarty @ 2009-01-23 19:12 UTC (permalink / raw)
To: git
In-Reply-To: <slrngnjafr.iaa.sitaramc@sitaramc.homelinux.net>
On 2009-01-23, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> I seem to recall (and the docs indicate) that when you
> *copy* (not move, just copy) a function from file1.c to
> file2.c, commit, and then do a "git blame -C -C file2.c", it
> should tell you that those lines came from file1.c
>
> Is this not true? Git 1.6.1, I tried this on a dummy branch
> where I just copied a good sized function (about 45 lines)
> from one C program and dumped it at the bottom of a second
> one, and neither the gui blame nor the CLI blame show me
> that the lines came from elsewhere.
>
> What am I doing wrong?
(replying to myself...)
It works when I give it three "-C" arguments. I thought it
was supposed to be 2 though.
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Junio C Hamano @ 2009-01-23 19:23 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Schindelin, git, René Scharfe
In-Reply-To: <8c5c35580901231040i380c6458x1a6103cd6f55c479@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
>>> The plan is to fix these limitations by extending --submodules to allow
>>> certain flags/options:
>>> a|c|r include any|checked out|registered submodules
>>> H resolve submodule HEAD to decide which tree to include
What do you mean by "decide"? If HEAD exists (iow, the submodule is
checked out), the tree of the commit recorded in the superproject's
gitlink entry is included in the result?
As I already said before, I doubt it makes much sense in the context of
the current git-archive to base the choise on checkout status.
Unless you are extending git-archive and giving it an ability to write out
the superproject index or the work tree as an archive, that is.
Just like git-grep lets you grep in the work tree files (limited to paths
that appear in the index), or grep in the contents registered to the index
when run with --cached, git-archive could make an archive out of your work
tree files or your index contents. Such an extension to git-archive may
be quite useful with or without submodules.
In such mode of operation, because you are dealing with the work tree when
run without --cached, it would make sense to say "Ah, the superproject
index wants v1.0 of the submodule, but the work tree has v2.0 of it
checked out, and we are writing out the work tree, so let's include v2.0
instead", and as a side effect of deciding which commit's tree to include
from each submodule, it naturally makes sense to exclude submodules that
are not checked out.
But otherwise I am not so sure what the point of H option would be.
^ permalink raw reply
* Re: [RFC/PATCH v3 2/3] sha1_file: prepare for adding alternates on demand
From: Johannes Schindelin @ 2009-01-23 19:54 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <8c5c35580901231035j31484249nf96e0e659b119a2b@mail.gmail.com>
Hi,
On Fri, 23 Jan 2009, Lars Hjemli wrote:
> On Fri, Jan 23, 2009 at 00:43, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 22 Jan 2009, Lars Hjemli wrote:
> >> + if (!quiet)
> >> + error("object directory %s does not exist; "
> >> + "check .git/objects/info/alternates.",
> >> + ent->base);
> >
> > FWIW my concern is not at all addressed. A future user of add_alt_odb()
> > (and possibly your users in rare cases, too) can trigger the error that
> > suggests looking into the alternates. Leaving the human user puzzled.
>
> Is it the phrasing of the error message that concerns you (when
> invoked from add_alt_odb())?
>
> If so, would something like this be ok/better?
>
> >> + if (!quiet)
> >> + error("Alternate object directory %s does not exist ",
> >> + ent->base);
That would almost certainly be better.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Johannes Schindelin @ 2009-01-23 19:57 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <8c5c35580901231040i380c6458x1a6103cd6f55c479@mail.gmail.com>
Hi,
On Fri, 23 Jan 2009, Lars Hjemli wrote:
> On Fri, Jan 23, 2009 at 00:44, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 22 Jan 2009, Lars Hjemli wrote:
> >
> >> The new --submodules option is used to trigger inclusion of checked out
> >> submodules in the archive.
> >>
> >> The implementation currently does not verify that the submodule has
> >> been registered as 'interesting' in .git/config, neither does it
> >> resolve the currently checked out submodule HEAD but instead uses the
> >> commit SHA1 recorded in the gitlink entry to identify the submodule
> >> root tree.
> >
> > Please understand that I skipped the rest of the patch.
>
> That's too bad, I hoped on some feedback from you on the part of the
> commit message which you didn't quote:
Well, you ignored my comments, so what do you expect me to do? Be happy?
There are two issues there:
- presence of a specific commit object being present in the repository
does not necessarily mean that it is reachable by any ref, and therefore
can mean that the tree/blob objects are not reachable, because it could
be an interrupted fetch; in all of Git, we try to assume that only
reachable objects are valid objects.
- presence of a specific commit in the supermodule is a _lousy_ indicator
that the user wants to include that submodule in the archive.
Until both issues are addresse, I will not dance a little song and be
merry over this issue.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] contrib git-resurrect: find traces of a branch name and resurrect it
From: Thomas Rast @ 2009-01-23 20:03 UTC (permalink / raw)
To: git; +Cc: Boyd Stephen Smith Jr., Junio C Hamano, Johannes Schindelin
In-Reply-To: <200901201450.53450.bss@iguanasuicide.net>
Add a tool 'git-resurrect.sh <branch>' that tries to find traces of
the <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>
---
Boyd Stephen Smith Jr. wrote:
> I think it could be quite nice; "undelete"-type commands are generally
> well-received by users and when run against reflogs alone, that's what the
> command is.
>
> It's useful enough to me that I'd love to see it mainlined.
So here's a version for contrib with more options and some other
tweaks.
I removed the ability to "batch resurrect" with several <name>
arguments since that would have conflicted with -b <newname>, but
otherwise the features are the same.
> In my particular case, it wasn't useful without the -m option, but I
> understand why it is not the default.
Aside from the obvious speed reasons, I don't really want to teach
people that commits "know" the branch they were on. It is a pure
coincidence if you can resurrect a topic branch from merge messages;
an equivalent merge could have gone through as a fast-forward, and
you'd never know.
contrib/git-resurrect.sh | 140 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 140 insertions(+), 0 deletions(-)
create mode 100755 contrib/git-resurrect.sh
diff --git a/contrib/git-resurrect.sh b/contrib/git-resurrect.sh
new file mode 100755
index 0000000..29bf723
--- /dev/null
+++ b/contrib/git-resurrect.sh
@@ -0,0 +1,140 @@
+#!/bin/sh
+
+USAGE="[-h] [-r] [-m] [-t] [-n] [-b <newname>] <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 messages, and with -r also merge messages. With
+-m and -t, the history of all refs is scanned for Merge <name> into
+other/Merge <other> into <name> (respectively) commit subjects, which
+is rather slow but allows you to resurrect other people's topic
+branches."
+
+OPTIONS_SPEC="\
+git resurrect [-h] [-r] [-m] [-t] [-n] [-b <newname>] <name>
+--
+b,branch= save branch as <newname> instead of <name>
+H,try-hard same as -r -m -t
+r,reflog-merges scan for merges recorded in reflog
+m,merges scan for merges into other branches (slow)
+t,merge-targets scan for merges of other branches into <name>
+n,dry-run don't recreate the branch"
+
+. git-sh-setup
+cd_to_toplevel
+
+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_reflog_merges=
+scan_merges=
+scan_merge_targets=
+new_name=
+
+while test "$#" != 0; do
+ case "$1" in
+ -b|--branch)
+ shift
+ new_name="$1"
+ ;;
+ -n|--dry-run)
+ dry_run=t
+ ;;
+ -m|--merges)
+ scan_merges=t
+ ;;
+ -r|--reflog_merges)
+ scan_reflog_merges=t
+ ;;
+ -t|--merge-targets)
+ scan_merge_targets=t
+ ;;
+ -H|--try-hard)
+ scan_reflog_merges=t
+ scan_merges=t
+ scan_merge_targets=t
+ ;;
+ --)
+ shift
+ break
+ ;;
+ *)
+ usage
+ ;;
+ esac
+ shift
+done
+
+test "$#" = 1 || usage
+
+branch="$1"
+test -z "$new_name" && new_name="$branch"q
+
+candidates="$(search_reflog $1)"
+if test ! -z "$scan_reflog_merges"; then
+ candidates="$candidates $(search_reflog_merges $1)"
+fi
+if test ! -z "$scan_merges"; then
+ candidates="$candidates $(search_merges $1)"
+fi
+if test ! -z "$scan_merge_targets"; then
+ candidates="$candidates $(search_merge_targets $1)"
+fi
+
+candidates="$(git rev-parse $candidates | sort -u)"
+
+if test -z "$candidates"; then
+ hint=
+ test "z$scan_merges$scan_reflog_merges$scan_merge_targets" != "zttt" \
+ && hint="(maybe try again with -H)"
+ die "no candidates for $branch found" $hint
+fi
+
+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 $new_name >/dev/null; then
+ printf "** Restoring $new_name to "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+ git branch $new_name $newest
+else
+ printf "Most recent: "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+ echo "** $new_name already exists, doing nothing"
+fi
--
1.6.1.447.gbdf1d
^ permalink raw reply related
* Re: [PATCH] Allow cloning an empty repository
From: Johannes Schindelin @ 2009-01-23 20:05 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <20090123165549.GI21473@genesis.frugalware.org>
Hi,
On Fri, 23 Jan 2009, Miklos Vajna wrote:
> On Fri, Jan 23, 2009 at 04:20:34AM +0100, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > But then, scripts have no business cloning repositories (fetching,
> > yes. But cloning?)
>
> I think portals like repo.or.cz may do it.
"git grep git.clone" in repo.git suggests that only clonecheck.sh uses it,
which is not called anywhere.
But more generally, the same should apply to such scripts as to human
users: HTTP _is_ 2nd class, and the fetch _could_ succeed later.
> Isn't setting errno (or similar variable) in the HTTP code an option?
> Then we could see why the transport failed and make a difference between
> "network error" and "no refs found".
I'd rather see the HTTP code path taken by transport.c _fail_ (i.e. die())
when there is some sort of connection error.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Change octal literals to be XEmacs friendly
From: Junio C Hamano @ 2009-01-23 20:13 UTC (permalink / raw)
To: malc; +Cc: git, Alexandre Julliard
In-Reply-To: <Pine.LNX.4.64.0901232158290.2186@linmac.oyster.ru>
malc <av1474@comtv.ru> writes:
> On Fri, 23 Jan 2009, Junio C Hamano wrote:
>
>> malc@pulsesoft.com writes:
>>
>>> case uses eql and (eql ?\001 1) evaluates to nil under XEmacs
>>> (probably because some internal type of ?\001 is char)
>>
>> And I presume the new way to spell is compatible with non XEmacs emacs?
>> It may be obvious to you, but please spell it out. Parenthesized
>> "probably" does not help building the confidence in the patch either.
>
> Fair enough.
>
> XEmacs:
> (type-of ?\1) yields character
>
> FSF Emacs:
> (type-of ?\1) yields integer
No use explaining that to me _here_. Please use that knowledge to write a
better description in an updated commit log message when sending your v2
patch.
>>> Signed-off-by: Vassili Karpov <av1474@comtv.ru>
>>
>> How are the (nameless) author of the patch malc@pulsesoft.com and Vassili
>> Karpov, the person who signed off, related?
>
> Both are my e-mail address used in ~/.gitconfig and ~/.emacs (and used
> by GNUS which was used to post the message via gmane's nntp interface)
> respectively.
Assuming that you would want to be known as Vassili, please have that name
on From: line of the message -- the patch acceptance tool takes the author
name from there.
If you can't for whatever reason use the name on From: line of the e-mail
message, you can begin the body of the message with
From: Vassili Karpov <av1474@comtv.ru>
(without indentation) and a blank line. This trick can also be used when
you are forwarding a patch somebody else wrote.
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Lars Hjemli @ 2009-01-23 20:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, René Scharfe
In-Reply-To: <7vzlhhu8qo.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 20:23, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>>>> The plan is to fix these limitations by extending --submodules to allow
>>>> certain flags/options:
>>>> a|c|r include any|checked out|registered submodules
>>>> H resolve submodule HEAD to decide which tree to include
>
> What do you mean by "decide"? If HEAD exists (iow, the submodule is
> checked out), the tree of the commit recorded in the superproject's
> gitlink entry is included in the result?
No, when H is specified the tree of the currently checked out
submodule commit would be included (this obviously shouldn't be the
default mode of operation, hence a flag to trigger it if that is what
the user wants).
>
> As I already said before, I doubt it makes much sense in the context of
> the current git-archive to base the choise on checkout status.
>
> Unless you are extending git-archive and giving it an ability to write out
> the superproject index or the work tree as an archive, that is.
>
> Just like git-grep lets you grep in the work tree files (limited to paths
> that appear in the index), or grep in the contents registered to the index
> when run with --cached, git-archive could make an archive out of your work
> tree files or your index contents. Such an extension to git-archive may
> be quite useful with or without submodules.
Absolutely.
>
> In such mode of operation, because you are dealing with the work tree when
> run without --cached, it would make sense to say "Ah, the superproject
> index wants v1.0 of the submodule, but the work tree has v2.0 of it
> checked out, and we are writing out the work tree, so let's include v2.0
> instead", and as a side effect of deciding which commit's tree to include
> from each submodule, it naturally makes sense to exclude submodules that
> are not checked out.
>
> But otherwise I am not so sure what the point of H option would be.
I would find the H flag practical for my own usage of submodules. I
almost never modify the content of the currently checked out submodule
but I often check out a different HEAD than what is registered in the
gitlink in the superproject (typically due to testing the superproject
against different versions of the submodule). And for such a use case,
being able to create a tarball of my currently checked out state seems
useful to me.
Anyways, if we get as far as adding a --submodules option to git
archive, I believe its default mode should be to archive the
superproject HEAD state together with the gitlink'd state of each
submodule registered in .git/config instead of --submodules=c which is
what this patch implements. But I wanted to get some feedback on this
plan before trying to implement it.
--
larsh
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Junio C Hamano @ 2009-01-23 20:50 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Schindelin, git, René Scharfe
In-Reply-To: <8c5c35580901231215q2be36abbla443975cdbb031f0@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> On Fri, Jan 23, 2009 at 20:23, Junio C Hamano <gitster@pobox.com> wrote:
>> Lars Hjemli <hjemli@gmail.com> writes:
>>
>>>>> The plan is to fix these limitations by extending --submodules to allow
>>>>> certain flags/options:
>>>>> a|c|r include any|checked out|registered submodules
>>>>> H resolve submodule HEAD to decide which tree to include
>>
>> What do you mean by "decide"? If HEAD exists (iow, the submodule is
>> checked out), the tree of the commit recorded in the superproject's
>> gitlink entry is included in the result?
>
> No, when H is specified the tree of the currently checked out
> submodule commit would be included.
That makes even less sense. At that point you are mixing a tree with
random state from a work tree, and doing so only for submodules. If you
want a work tree snapshot, it should be a work tree snapshot, and should
not be labelled as a snapshot out of a tree object of the superproject.
> I would find the H flag practical for my own usage of submodules. I
> almost never modify the content of the currently checked out submodule
> but I often check out a different HEAD than what is registered in the
> gitlink in the superproject (typically due to testing the superproject
> against different versions of the submodule). And for such a use case,
> being able to create a tarball of my currently checked out state seems
> useful to me.
That would be more like an enhanced version of "git archive" that takes
the work tree state, similar to how "git grep" operates on the work tree
today.
I agree that would be useful, but I have a moderately strong suspition
that your "H" hack that includes the work tree state for checked out
submodules into a view that is primarily about the "tree" object in the
superproject, without the same "take from the work tree" semantics for
paths in the superproject, is more harmful than being helpful to the users
in the longer term. It might be simple to implement, but I do not think
its semantics can be explained sanely.
^ permalink raw reply
* Re: [PATCH] Change octal literals to be XEmacs friendly
From: malc @ 2009-01-23 19:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alexandre Julliard
In-Reply-To: <7vbpty1m1r.fsf@gitster.siamese.dyndns.org>
On Fri, 23 Jan 2009, Junio C Hamano wrote:
> malc@pulsesoft.com writes:
>
>> case uses eql and (eql ?\001 1) evaluates to nil under XEmacs
>> (probably because some internal type of ?\001 is char)
>
> And I presume the new way to spell is compatible with non XEmacs emacs?
> It may be obvious to you, but please spell it out. Parenthesized
> "probably" does not help building the confidence in the patch either.
Fair enough.
XEmacs:
(type-of ?\1) yields character
FSF Emacs:
(type-of ?\1) yields integer
>
>> Signed-off-by: Vassili Karpov <av1474@comtv.ru>
>
> How are the (nameless) author of the patch malc@pulsesoft.com and Vassili
> Karpov, the person who signed off, related?
Both are my e-mail address used in ~/.gitconfig and ~/.emacs (and used
by GNUS which was used to post the message via gmane's nntp interface)
respectively.
> Next time, please spend a few minutes to see if there are active
> developers who are familiar in the area you are touching, and Cc your
> patch to ask their input.
>
> git blame -L562,+29 contrib/emacs/git.el
>
Okay.
> tells me that most of this came from 40f162b (git.el: Display file types
> and type changes., 2008-01-06) by Alexandre, so I am Cc'ing him.
>
[..snip..]
--
mailto:av1474@comtv.ru
^ permalink raw reply
* Re: [PATCH] contrib git-resurrect: find traces of a branch name and resurrect it
From: Boyd Stephen Smith Jr. @ 2009-01-23 21:00 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <1232740985-4551-1-git-send-email-trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]
On Friday 2009 January 23 14:03:05 Thomas Rast wrote:
>Boyd Stephen Smith Jr. wrote:
>> I think it could be quite nice; "undelete"-type commands are generally
>> well-received by users and when run against reflogs alone, that's what the
>> command is.
>>
>> It's useful enough to me that I'd love to see it mainlined.
>
>So here's a version for contrib with more options and some other
>tweaks.
I wanted/needed the ability to ignore reflogs entirely. Use went something
like this:
1. resurrect branch from origin/pu
2. add patches, mail to list
3. # wait 24 hours
4. pull, see from logs that branch was modified, but not just my changes (or
without all of my changes).
5. delete local branch
6. Try to resurrect branch from origin/pu, get local version I just deleted.
7. delete reflog for that branch
8. Try to resurrect branch from origin/pu, get local version I merged into
master at some point.
9. Add new option.
So, I added a couple of options locally: --only-merges, so it would only look
at the first line of commit logs, ignoring my local reflogs entirely;
and --revisions, to specify arguments to pass to rev-list so it wouldn't even
see my local merges (I passed 'origin/pu origin/next').
Yeah, my usage might be abusage, but it worked for me. :)
Would you object to a patch adding a --reflog option and allowing each of the
scan options to be negated?
>I removed the ability to "batch resurrect" with several <name>
>arguments since that would have conflicted with -b <newname>, but
>otherwise the features are the same.
In my local version, which I was going to try and clean up over the weekend, I
was going to support both, by borrowing refspec syntax from fetch/push.
Specifically. Resurrecting 'js/notes' as 'pu/js/notes' would look like:
git-resurrect -H js/notes:pu/js/notes
Would you object to a patch that dropped -b in favor of the refspec syntax?
>> In my particular case, it wasn't useful without the -m option, but I
>> understand why it is not the default.
>
>Aside from the obvious speed reasons, I don't really want to teach
>people that commits "know" the branch they were on. It is a pure
>coincidence if you can resurrect a topic branch from merge messages;
>an equivalent merge could have gone through as a fast-forward, and
>you'd never know.
Yeah, agreed. I made this more clear in my local version by changing the
documentation from "scan for merges" to "scan first line of commit messages
for possible merges". It's more wordy, but it make it clear that it is
dependent on the message, and it's not tracked outside of that.
I also tend to merge topic branches with --no-ff so that I do get the merge
message, so it has a better chance of working against my repository. (I also
enjoy octopus merging when possible so the history indicates the patch sets
are separable, but maybe I'm just a little "touched" and haven't been bitten
by by an octopus yet.[1])
Not directly related to any issue you bring up:
There seems to be some needless redundancy between USAGE and OPTIONS_SPEC.
Would you object to a patch that used $USAGE inside OPTIONS_SPEC?
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[1] I hear they are even more feral than penguins.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Lars Hjemli @ 2009-01-23 21:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, René Scharfe
In-Reply-To: <7vljt1u4pc.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 21:50, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>> I would find the H flag practical for my own usage of submodules. I
>> almost never modify the content of the currently checked out submodule
>> but I often check out a different HEAD than what is registered in the
>> gitlink in the superproject (typically due to testing the superproject
>> against different versions of the submodule). And for such a use case,
>> being able to create a tarball of my currently checked out state seems
>> useful to me.
>
> That would be more like an enhanced version of "git archive" that takes
> the work tree state, similar to how "git grep" operates on the work tree
> today.
>
> I agree that would be useful, but I have a moderately strong suspition
> that your "H" hack that includes the work tree state for checked out
> submodules into a view that is primarily about the "tree" object in the
> superproject, without the same "take from the work tree" semantics for
> paths in the superproject, is more harmful than being helpful to the users
> in the longer term. It might be simple to implement, but I do not think
> its semantics can be explained sanely.
Ok. When someone gets the itch for 'git archive --worktree', it would
be easy enough to resurrect the idea of including the tree of the
currently checked out HEAD in selected submodules.
Do you think the other options makes any sense, i.e. is it any point
in me trying to implement this?
--
larsh
^ permalink raw reply
* [PATCH (GIT-GUI BUG)] git-gui: Fix post-commit status with subject in non-locale encoding.
From: Alexander Gavrilov @ 2009-01-23 21:18 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Robin Rosenberg
As pointed out in msysgit bug #181, when a non-locale encoding
is used for commits, post-commit status messages display the
subject incorrectly. It happens because the file handle is
not properly configured before the subject is read back.
This patch fixes it by factoring out the code that is
used to setup the output handle into a separate function,
and calling it from the reading code.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
The original bug report:
http://code.google.com/p/msysgit/issues/detail?id=181
lib/commit.tcl | 29 +++++++++++++++++++----------
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/lib/commit.tcl b/lib/commit.tcl
index 9cc8410..17aba91 100644
--- a/lib/commit.tcl
+++ b/lib/commit.tcl
@@ -115,6 +115,23 @@ proc create_new_commit {} {
rescan ui_ready
}
+proc setup_commit_encoding {msg_wt {quiet 0}} {
+ global repo_config
+
+ if {[catch {set enc $repo_config(i18n.commitencoding)}]} {
+ set enc utf-8
+ }
+ set use_enc [tcl_encoding $enc]
+ if {$use_enc ne {}} {
+ fconfigure $msg_wt -encoding $use_enc
+ } else {
+ if {!$quiet} {
+ error_popup [mc "warning: Tcl does not support encoding '%s'." $enc]
+ }
+ fconfigure $msg_wt -encoding utf-8
+ }
+}
+
proc commit_tree {} {
global HEAD commit_type file_states ui_comm repo_config
global pch_error
@@ -200,16 +217,7 @@ A good commit message has the following format:
set msg_p [gitdir GITGUI_EDITMSG]
set msg_wt [open $msg_p w]
fconfigure $msg_wt -translation lf
- if {[catch {set enc $repo_config(i18n.commitencoding)}]} {
- set enc utf-8
- }
- set use_enc [tcl_encoding $enc]
- if {$use_enc ne {}} {
- fconfigure $msg_wt -encoding $use_enc
- } else {
- error_popup [mc "warning: Tcl does not support encoding '%s'." $enc]
- fconfigure $msg_wt -encoding utf-8
- }
+ setup_commit_encoding $msg_wt
puts $msg_wt $msg
close $msg_wt
@@ -362,6 +370,7 @@ A rescan will be automatically started now.
append reflogm " ($commit_type)"
}
set msg_fd [open $msg_p r]
+ setup_commit_encoding $msg_fd 1
gets $msg_fd subject
close $msg_fd
append reflogm {: } $subject
--
1.6.1.63.g950db
^ permalink raw reply related
* Re: [PATCH] gittutorial: remove misleading note
From: Miklos Vajna @ 2009-01-23 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk58lvoe5.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
On Fri, Jan 23, 2009 at 11:00:18AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> So we have a usability regression here. Perhaps we need to fix that
> instead?
I thought that's on purpose.
By doing a 'git fetch <url>' I don't say "what" to fetch, just "from
where".
Would it be better to fetch HEAD in that case?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: egit problem with sym linked eclipse project dirs
From: Robin Rosenberg @ 2009-01-23 21:33 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: Shawn O. Pearce, git
In-Reply-To: <p06240812c59ed365d694@[192.168.1.106]>
fredag 23 januari 2009 02:56:16 skrev Stephen Bannasch:
> At 6:27 PM -0500 1/13/09, Stephen Bannasch wrote:
...
> >Done: http://code.google.com/p/egit/issues/detail?id=52
> >
> >Fxing this will make using Eclipse and Git together SO much nicer!
>
> Robin and Shawn,
>
> Can you suggest where in the egit code I should look to see if I can fix this?
There may be more than one place.
Take a look at GitResourceDecorator.
We map from resources using code like this:
RepositoryMapping.getMapping(rsrc) // <-- prime suspect
Repository.getRepoRelativePath(rsrc)
Repository.getWorkDir
Repository.isResourceChanged
I'm not entirely sure this is the correct way, but it probably has no
bearing on your problem.
GitResourceDecorator decorator = getActiveDecorator();
It would be nice with a unit test for this. (Not necessarily the decorator,
but the methods used for it).
-- robin
^ permalink raw reply
* Re: [JGIT PATCH 02/10] Expose the raw path for the current entry of a TreeWalk
From: Robin Rosenberg @ 2009-01-23 21:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1232666890-23488-3-git-send-email-spearce@spearce.org>
fredag 23 januari 2009 00:28:02 skrev Shawn O. Pearce:
> Copying the path byte array (keeping it encoded in UTF-8) is quicker
> than converting to String and then back again to UTF-8 when creating
> a DirCacheEntry for the current position in a TreeWalk.
[...]
> + * Get the current entry's complete path as a UTF-8 byte array.
/Hopefully/ UTF-8. It is often a legacy encoding, like ISO-8859-X, CP12xx
etc. I'll come up with something less specific that just UTF-8.
-- robin
^ permalink raw reply
* [RFC PATCH (GIT-GUI/CORE BUG)] git-gui: Avoid an infinite rescan loop in handle_empty_diff.
From: Alexander Gavrilov @ 2009-01-23 21:52 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano, Andy Davey, kbro
If the index update machinery and git diff happen to disagree
on whether a particular file is modified, it may cause git-gui
to enter an infinite index rescan loop, where an empty diff
starts a rescan, which finds the same set of files modified,
and tries to display the diff for the first one, which happens
to be the empty one. A current example of a possible disagreement
point is the autocrlf filter.
This patch breaks the loop by using a global variable to track
the auto-rescans. The variable is reset whenever a non-empty
diff is displayed. As a way to work around the malfunctioning
index rescan command, it resurrects the pre-0.6.0 code that
directly updates only the affected file.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
Note that if the file is actually modified, and the bug is
either in git-diff or the way git-gui calls it, this patch
will stage the file without displaying it in the UI. Thus, it
may be better to simply do nothing if the loop prevention
logic triggers.
On Jan 22, 11:31 pm, kbro <kevin.broa...@googlemail.com> wrote:
> However, for me it was worse as the "No differences" message popped up
> as soon as I opened git-gui, and the dialog said it would run a rescan
> to find all files in a similar state. The rescan caused the same
> error to be detected again, so I could never get the dialog box to go
> away.
On Friday 23 January 2009 02:56:23 Andy Davey wrote:
> I had the exact same problem you described running git-1.6.1-
> preview20081227 on Windows XP as well. (the endless loop of dialog box
> is very frustrating).
P.S. Steps to reproduce the autocrlf handling mismatch on Linux:
$ git init
$ echo > foo
$ git add foo && git commit -m init
$ unix2dos -o foo
$ git config core.autocrlf true
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: foo
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git diff foo
diff --git a/foo b/foo
It happens because git-status assumes that a change in
file size always means that the file contents have changed.
Content filters like autocrlf may invalidate this assumption.
lib/diff.tcl | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index bbbf15c..e5abb49 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -51,6 +51,7 @@ proc force_diff_encoding {enc} {
proc handle_empty_diff {} {
global current_diff_path file_states file_lists
+ global last_empty_diff
set path $current_diff_path
set s $file_states($path)
@@ -66,7 +67,17 @@ A rescan will be automatically started to find other files which may have the sa
clear_diff
display_file $path __
- rescan ui_ready 0
+
+ if {![info exists last_empty_diff]} {
+ set last_empty_diff $path
+ rescan ui_ready 0
+ } else {
+ # We already tried rescanning recently, and it failed,
+ # so resort to updating this particular file.
+ if {[catch {git update-index -- $path} err]} {
+ error_popup [mc "Failed to refresh index:\n\n%s" $err]
+ }
+ }
}
proc show_diff {path w {lno {}} {scroll_pos {}} {callback {}}} {
@@ -310,6 +321,7 @@ proc read_diff {fd cont_info} {
global ui_diff diff_active
global is_3way_diff is_conflict_diff current_diff_header
global current_diff_queue
+ global last_empty_diff
$ui_diff conf -state normal
while {[gets $fd line] >= 0} {
@@ -415,6 +427,8 @@ proc read_diff {fd cont_info} {
if {[$ui_diff index end] eq {2.0}} {
handle_empty_diff
+ } else {
+ catch { unset last_empty_diff }
}
set callback [lindex $cont_info 1]
if {$callback ne {}} {
--
1.6.1.63.g950db
^ permalink raw reply related
* Re: [PATCH] Allow cloning an empty repository
From: Mike Hommey @ 2009-01-23 21:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901230333060.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 03:42:24AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 23 Jan 2009, Sverre Rabbelier wrote:
>
> > On Fri, Jan 23, 2009 at 02:24, Junio C Hamano <gitster@pobox.com> wrote:
> > > I think the basic idea is Ok, but is it a reliable check at this point to
> > > see if (refs == NULL) to tell if the target repository is an empty one?
> >
> > This is the question I asked Dscho, and he said/guessed that it was.
> >
> > > I am mostly worried about a failure case (connected but couldn't get
> > > the refs, or perhaps connection failed to start). If you get a NULL
> > > in such a case you may end up saying "oh you cloned a void" when you
> > > should say "nah, such a remote repository does not exist".
> >
> > Yes, this was my concern as well.
>
> From what I can see in get_remote_heads(), the native protocols would
> die(), as would rsync().
>
> HTTP transport, however, would not die() on connection errors, from my
> cursory look.
>
> That might be skewed, though, as I am on top of Mike's patches (in the
> hopefully not so futile hope that Mike -- after letting me wait for over
> one year -- finishes his work.
As I said when posting my patch batch, I don't have much time nor
motivation to work on this series. But let's make a deal: if someone
writes a good enough http test suite, I'll polish the http code.
Mike
^ permalink raw reply
* Re: [PATCHv2] git mergetool: Don't repeat merge tool candidates
From: Junio C Hamano @ 2009-01-23 22:10 UTC (permalink / raw)
To: Johannes Gilger; +Cc: git, tytso
In-Reply-To: <1232702093-24313-1-git-send-email-heipei@hackvalue.de>
Johannes Gilger <heipei@hackvalue.de> writes:
> git mergetool listed some candidates for mergetools twice, depending on
> the environment.
>
> Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
> ---
> The first patch had the fatal flaw that it listed nothing when DISPLAY
> and EDITOR/VISUAL were unset, we fixed that.
> The order in which merge-candidates appear is still exactly the same,
> only duplicates have been stripped. The check for KDE_FULL_SESSION was
> removed since kdiff3 was added as long as DISPLAY was set and we weren't
> running gnome.
The old code produced this:
DISPLAY set
| GNOME_DESKTOP_SESSION_ID set
| | KDE_FULL_SESSION true
| | |
- - - (editor)
- - + (editor)
- + - (editor)
- + + (editor)
+ - - kdiff3 tkdiff xxdiff meld gvimdiff (editor)
+ - + kdiff3 kdiff3 tkdiff xxdiff meld gvimdiff (editor)
+ + - meld kdiff3 tkdiff xxdiff meld gvimdiff (editor)
+ + + kdiff3 meld kdiff3 tkdiff xxdiff meld gvimdiff (editor)
where (editor) lists emerge or vimdiff if the preferred editor was emacs
or vim, and then opendiff, and then emerge and vimdiff as fallback
duplicates.
Looking at what the new code does for the (editor) fallback part first:
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
merge_tool_candidates="$merge_tool_candidates emerge opendiff vimdiff"
fi
if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
merge_tool_candidates="$merge_tool_candidates vimdiff opendiff emerge"
fi
if test -z "$merge_tool_candidates" ; then
merge_tool_candidates="opendiff emerge vimdiff"
fi
I think it is better to rewrite this part for clarity:
if EDITOR is emacs?
then
append emerge opendiff vimdiff in this order
elif EDITOR is vim?
then
append vimdiff opendiff emerge in this order
else
append opendiff emerge vimdiff in this order
fi
because emacs and vim cannot be set to EDITOR at the same time
(note that I think this also fixes a bug; see below).
> if test -n "$DISPLAY"; then
> if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
> + merge_tool_candidates="meld kdiff3 tkdiff xxdiff gvimdiff"
> + else
> + merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
> fi
> fi
This one produces:
DISPLAY set
| GNOME_DESKTOP_SESSION_ID set
| | KDE_FULL_SESSION true
| | |
- - - (editor)
- - + (editor)
- + - (editor)
- + + (editor)
+ - - kdiff3 tkdiff xxdiff meld gvimdiff (editor')
+ - + kdiff3 tkdiff xxdiff meld gvimdiff (editor')
+ + - meld kdiff3 tkdiff xxdiff gvimdiff (editor')
+ + + meld kdiff3 tkdiff xxdiff gvimdiff (editor')
where "(editor')" is empty if your EDITOR is not emacs nor vim.
The original list with the duplicates removed is:
DISPLAY set
| GNOME_DESKTOP_SESSION_ID set
| | KDE_FULL_SESSION true
| | |
- - - (editor)
- - + (editor)
- + - (editor)
- + + (editor)
+ - - kdiff3 tkdiff xxdiff meld gvimdiff (editor)
+ - + kdiff3 tkdiff xxdiff meld gvimdiff (editor)
+ + - meld kdiff3 tkdiff xxdiff gvimdiff (editor)
+ + + kdiff3 meld tkdiff xxdiff gvimdiff (editor)
Aside from the "(editor') is empty when DISPLAY is set" difference, the
result is also different iff GNOME_DESKTOP_SESSION_ID and KDE_FULL_SESSION
are both set. I am guessing that that does not happen in a sane
environment, though.
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Jeff King @ 2009-01-23 22:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git list, Christian MICHON
In-Reply-To: <7vtz7qxsxc.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 01:39:27AM -0800, Junio C Hamano wrote:
> > --->8---
> > Subject: [PATCH] git-am: Add --ignore-date option
>
> Good.
>
> Leaving "Subject: " in saves me typing, because I do not have to insert it
> manually when editing the submitted patch in my MUA to chop off everything
> before the scissors.
Interesting to know. I have intentionally _not_ been including them,
because I assumed you marked up _after_ git-am (i.e., via "git commit
--amend) in which case you would have to delete it manually. I suppose
it makes more sense to do so before git-am, though, since then it will
respect From: fields and the like (which it would otherwise ignore,
since they are blocked by all of the cover letter cruft that you will
end up deleting).
So good to know, and I will start generating my patches differently.
-Peff
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Jeff King @ 2009-01-23 22:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901230419080.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 04:20:34AM +0100, Johannes Schindelin wrote:
> Probably. Note, however, that scripts might rely on a fail if there were
> problems.
>
> But then, scripts have no business cloning repositories (fetching, yes.
> But cloning?)
Really? I have scripts that call clone (usually followed by building the
result). Are you proposing that all scripts should "git init && git
remote add && git fetch"?
So I am strongly in favor of telling the difference between failure and
emptiness.
-Peff
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Sverre Rabbelier @ 2009-01-23 22:34 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20090123223205.GA11491@coredump.intra.peff.net>
On Fri, Jan 23, 2009 at 23:32, Jeff King <peff@peff.net> wrote:
> Really? I have scripts that call clone (usually followed by building the
> result). Are you proposing that all scripts should "git init && git
> remote add && git fetch"?
>
> So I am strongly in favor of telling the difference between failure and
> emptiness.
A switch then, '--allow-empty'?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Jeff King @ 2009-01-23 22:37 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <bd6139dc0901231434n6d6af5a6ma8bb12a634d5b3ba@mail.gmail.com>
On Fri, Jan 23, 2009 at 11:34:04PM +0100, Sverre Rabbelier wrote:
> On Fri, Jan 23, 2009 at 23:32, Jeff King <peff@peff.net> wrote:
> > Really? I have scripts that call clone (usually followed by building the
> > result). Are you proposing that all scripts should "git init && git
> > remote add && git fetch"?
> >
> > So I am strongly in favor of telling the difference between failure and
> > emptiness.
>
> A switch then, '--allow-empty'?
No, I don't mind success on cloning an empty repository. But I thought
the issue at hand was that for some instances, we would report that we
successfully created an empty repository, when in fact what happened was
that we failed to clone a non-empty repository. And that that was
fixable, but it was a problem with our code interfaces (which should be
fixable) and not some fundamental limitation.
Or am I misunderstanding the situation?
-Peff
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Sverre Rabbelier @ 2009-01-23 22:39 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20090123223740.GA11527@coredump.intra.peff.net>
On Fri, Jan 23, 2009 at 23:37, Jeff King <peff@peff.net> wrote:
> No, I don't mind success on cloning an empty repository. But I thought
> the issue at hand was that for some instances, we would report that we
> successfully created an empty repository, when in fact what happened was
> that we failed to clone a non-empty repository. And that that was
> fixable, but it was a problem with our code interfaces (which should be
> fixable) and not some fundamental limitation.
Ah, mhh, if that is the case then I'm afraid that's beyond me (at
least for now), someone else would have to do said refactoring first
:(.
> Or am I misunderstanding the situation?
I think you summarized it pretty well, if that is indeed what Junio meant.
--
Cheers,
Sverre Rabbelier
^ 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