* Re: [RFC] Introduce .git/BRANCH to point to the current branch
From: Junio C Hamano @ 2007-12-04 20:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthieu Moy, Salikh Zakirov, Git Mailing List
In-Reply-To: <m34peyur8r.fsf@roke.D-201>
Jakub Narebski <jnareb@gmail.com> writes:
>> Currently, I can do:
>>
>> # Oh, what did this look like two commits ago?
>> $ git checkout HEAD^^
>> # Ah, OK, let's go back to the tip
>> $ git checkout branch-name
>> ^^^^^^^^^^^
>> But I have to remember and re-type the branch name.
>
> No, you don't have. You can use
> $ git checkout ORIG_HEAD
> or
> $ git checkout HEAD@{1}
But the point is he wants to go back to the branch he came from. He
does not want to detach HEAD at the original commit.
Having said that, I am not sympathetic to "I have to remember".
^ permalink raw reply
* Re: [RFC] Introduce .git/BRANCH to point to the current branch
From: Jakub Narebski @ 2007-12-04 20:42 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Salikh Zakirov, Git Mailing List
In-Reply-To: <vpqbq96jjrf.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Salikh Zakirov <salikh@gmail.com> writes:
>
> > This combination leads to the confusing user experience
> > if the branch changes independently of the working directory.
> > This can happen in following cases:
All those cases are cases of not recommended workflows.
Please search the archives for idea of BASE extension to index
(instead of your separate file under .git/refs), and why it is
not in current git.
BTW. how in your proposal would you detach HEAD?
> There's another thing that your proposal could change: navigating back
> in history without loosing track of the branch you're on.
>
> Currently, I can do:
>
> # Oh, what did this look like two commits ago?
> $ git checkout HEAD^^
> # Ah, OK, let's go back to the tip
> $ git checkout branch-name
> ^^^^^^^^^^^
> But I have to remember and re-type the branch name.
No, you don't have. You can use
$ git checkout ORIG_HEAD
or
$ git checkout HEAD@{1}
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: [RFC] Introduce .git/BRANCH to point to the current branch
From: Matthieu Moy @ 2007-12-04 20:19 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: Git Mailing List
In-Reply-To: <4755B3B3.80704@gmail.com>
Salikh Zakirov <salikh@gmail.com> writes:
> This combination leads to the confusing user experience
> if the branch changes independently of the working directory.
> This can happen in following cases:
There's another thing that your proposal could change: navigating back
in history without loosing track of the branch you're on.
Currently, I can do:
# Oh, what did this look like two commits ago?
$ git checkout HEAD^^
# Ah, OK, let's go back to the tip
$ git checkout branch-name
^^^^^^^^^^^
But I have to remember and re-type the branch name.
I can imagine (not tested with your patch) doing just:
$ git checkout HEAD^^
$ git checkout BRANCH
(that's one point in favor of your change, but I'm not familiar enough
with git's internal to say whether this is sufficient to justify the
change).
--
Matthieu
^ permalink raw reply
* Re: git help error
From: Luciano Rocha @ 2007-12-04 20:06 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <863auiw86m.fsf@lola.quinscape.zz>
[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]
On Tue, Dec 04, 2007 at 08:50:41PM +0100, David Kastrup wrote:
> Luciano Rocha <strange@nsk.no-ip.org> writes:
>
> > On Tue, Dec 04, 2007 at 11:40:15AM -0800, Junio C Hamano wrote:
> >
> >> Having said that, I do not mind accepting a patch that prepends the
> >> nonlocal path to MANPATH in help.c::show_man_page().
> >
> > Actually, current man utilities locate the manual page by looking where
> > the executable is, if MANPATH isn't defined (tested in Linux and
> > Darwin).
> >
> > So, "unset MANPATH; man git-add" should be sufficient.
>
> That only works for paths registered in /etc/manpath.config (or an
> equivalent config file depending on system/distribution).
Err, no. I doubt my ~/opt/noarch/.../...; ~/opt/`uname -i`/git/; etc.,
are pre-registered by my Linux distro or OS X 10.[45].
man man:
If you specify the -M pathlist option, pathlist is a colon-separated
list of the directories that man searches.
If you don’t specify -M but set the MANPATH environment variable, the
value of that variable is the list of the directories that man
searches.
If you don’t specify an explicit path list with -M or MANPATH, man
develops its own path list based on the contents of the configuration
file /etc/man.config. The MANPATH statements in the configuration file
identify particular directories to include in the search path.
...
In addition, for each directory in the command search path (we’ll call
it a "command directory") for which you do not have a MANPATH_MAP
statement, man automatically looks for a manual page directory "nearby"
namely as a subdirectory in the command directory itself or in the par-
ent directory of the command directory.
So, according to the last paragraph, and assuming no -M argument and no
MANPATH environment variable are defined, man should be able to find the
manual pages for git commands if they're in PATH.
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [RFC] Introduce .git/BRANCH to point to the current branch
From: Salikh Zakirov @ 2007-12-04 20:08 UTC (permalink / raw)
To: Git Mailing List
Before this change, .git/HEAD file played two roles:
(a) point to the base commit of the working directory
(b) point to current branch
This combination leads to the confusing user experience
if the branch changes independently of the working directory.
This can happen in following cases:
1) git clone repo repo2
cd repo2
... edit something
git commit -a
git push
2) checking out the same branch in the another working directory
associated with the same repository, e.g. created by
contrib/workdir/git-new-workdir
git new-workdir repo repo2
cd repo2
... edit something
git commit -a
In both cases original repository will report differences between
index and HEAD, even if though particular working directory
state has not been changed at all.
This patch separates the notion of the current branch from
the base commit. HEAD will always be "detached", and will store
the hash of the base commit. Newly introduced BRANCH reference
will point to the current branch.
When new commit is created, it is first stored in the HEAD.
Then HEAD is compared to the branch head (BRANCH), and branch
head is updated only if it is fast forward.
So, in all simple case there will be no difference in the workflow.
In the "irregular" use cases above, branch head may diverge from
the base commit of the repository. This situation is detected
by the updaters of the HEAD, and user is advised to run merge.
---
Unfortunately, I have not figured out how to set up an empty repository
to use separate HEAD and BRANCH, so one needs to set up an existing
repository manually in order to play with this change:
git rev-parse HEAD > .git/HEAD.new
mv .git/HEAD .git/BRANCH
mv .git/HEAD.new .git/HEAD
The way branch head is updated after HEAD update in this patch
is clearly unacceptable, as it causes too much code duplication.
I wonder if it would be better to introduce a special case in git-update-ref?
git-checkout.sh | 4 +++-
git-commit.sh | 16 ++++++++++++++++
git-merge.sh | 15 +++++++++++++++
wt-status.c | 11 +++++++----
wt-status.h | 1 +
5 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index f6d58ac..8e1a1ab 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -266,7 +266,9 @@ if [ "$?" -eq 0 ]; then
if test -n "$branch"
then
old_branch_name=`expr "z$oldbranch" : 'zrefs/heads/\(.*\)'`
- GIT_DIR="$GIT_DIR" git symbolic-ref -m "checkout: moving from ${old_branch_name:-$old} to $branch" HEAD "refs/heads/$branch"
+ GIT_DIR="$GIT_DIR" git symbolic-ref -m "checkout: moving from ${old_branch_name:-$old} to $branch" BRANCH "refs/heads/$branch"
+ commit=$(git rev-parse --verify BRANCH 2>/dev/null) &&
+ git update-ref --no-deref -m "checkout: moving from ${old_branch_name:-$old} to $branch" HEAD "$commit"
if test -n "$quiet"
then
true # nothing
diff --git a/git-commit.sh b/git-commit.sh
index 2c4a406..b7315c1 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -609,7 +609,23 @@ then
mv "$NEXT_INDEX" "$THIS_INDEX"
else
: ;# happy
+ fi && {
+ branchhead=$(git rev-parse --verify BRANCH 2>/dev/null)
+ if test -n "$branchhead"
+ then
+ if test -z "`git rev-list $commit..$branchhead`"
+ then
+ # fast-forward, update the branch pointer as well
+ git update-ref -m "$GIT_REFLOG_ACTION: $rlogm" BRANCH $commit "$branchhead"
+ else
+ name=$(git symbolic-ref BRANCH | sed 's,refs/heads/,,')
+ echo >&2 "* HEAD diverged from $name"
+ echo >&2 "* Consider 'git merge $name'"
+ fi
+ else
+ git-update-ref -m "$GIT_REFLOG_ACTION: $rlogm" BRANCH $commit "$branchhead"
fi
+ }
else
echo >&2 "* no commit message? aborting commit."
false
diff --git a/git-merge.sh b/git-merge.sh
index 1c123a3..3d4b31b 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -94,6 +94,21 @@ finish () {
*)
git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
git gc --auto
+ branchhead=$(git rev-parse --verify BRANCH 2>/dev/null)
+ if test -n "$branchhead"
+ then
+ if test -z "`git rev-list $commit..$branchhead`"
+ then
+ # fast-forward, update the branch pointer as well
+ git update-ref -m "$rlogm" BRANCH "$1" "$branchhead" || exit 1
+ else
+ name=$(git symbolic-ref BRANCH | sed 's,refs/heads/,,')
+ echo >&2 "* HEAD diverged from $name"
+ echo >&2 "* Consider 'git merge $name'"
+ fi
+ else
+ git-update-ref -m "$GIT_REFLOG_ACTION: $rlogm" BRANCH $commit "$branchhead"
+ fi
;;
esac
;;
diff --git a/wt-status.c b/wt-status.c
index bf2fe8d..9fe5d10 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -44,12 +44,14 @@ static const char* color(int slot)
void wt_status_prepare(struct wt_status *s)
{
- unsigned char sha1[20];
- const char *head;
+ unsigned char sha1[20], sha2[20];
+ const char *head, *branch;
memset(s, 0, sizeof(*s));
head = resolve_ref("HEAD", sha1, 0, NULL);
- s->branch = head ? xstrdup(head) : NULL;
+ branch = resolve_ref("BRANCH", sha2, 0, NULL);
+ s->diverged = hashcmp(sha1, sha2);
+ s->branch = branch ? xstrdup(branch) : NULL;
s->reference = "HEAD";
s->fp = stdout;
s->index_file = get_index_file();
@@ -309,6 +311,7 @@ void wt_status_print(struct wt_status *s)
if (s->branch) {
const char *on_what = "On branch ";
const char *branch_name = s->branch;
+ const char *diverged = (s->diverged ? ", diverged" : "");
if (!prefixcmp(branch_name, "refs/heads/"))
branch_name += 11;
else if (!strcmp(branch_name, "HEAD")) {
@@ -316,7 +319,7 @@ void wt_status_print(struct wt_status *s)
on_what = "Not currently on any branch.";
}
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER),
- "# %s%s", on_what, branch_name);
+ "# %s%s%s", on_what, branch_name, diverged);
}
if (s->is_initial) {
diff --git a/wt-status.h b/wt-status.h
index 7744932..db8129d 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -17,6 +17,7 @@ struct wt_status {
int verbose;
int amend;
int untracked;
+ int diverged;
/* These are computed during processing of the individual sections */
int commitable;
int workdir_dirty;
--
1.5.3.5.610.g3532b
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Steffen Prohaska @ 2007-12-04 20:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <47552084.3070601@viscovery.net>
On Dec 4, 2007, at 10:40 AM, Johannes Sixt wrote:
> Junio C Hamano schrieb:
>> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
>> + refactor fetch's ref matching to use refname_match()
>> + push: use same rules as git-rev-parse to resolve refspecs
>> + add refname_match()
>> + push: support pushing HEAD to real branch name
>> The last one changes the semantics to somewhat less safe:
>> * We did not allow fetching outside refs/ (except HEAD), but
>> now we
>> allow any random string.
>> * We used to restrict fetching names that do not begin with
>> refs/ to
>> heads, tags and remotes, but now the code grabs anything
>> underneath
>> refs/.
>> which could invite mistakes by letting typos slip through, but I
>> won't
>> be a good judge, as I probably "fetch" much less often than other
>> people
>> do and these may be non issues in the real-world usecases. It
>> could be
>> that I am worried too much needlessly. If anybody who is following
>> 'next' has been bitten by the change, please speak up. Otherwise
>> this
>> will go in soon.
>
> Forks on repo.or.cz use the namespace refs/forkee that lists
> everything that the forkee has below refs/. So this change might
> indeed be annoying. (But I'm not using next, so I can't tell, yet.)
But only if you accidentally wrote
git fetch forkee/heads/something
instead of
git fetch heads/something
which I don't think is a very likely typo.
With the last change, fetch still requires a match of the full
refspec created by prefixing a short refspec with "refs/".
Different from the old behaviour, it does no longer verify
that the short refspec from the command line starts with
heads, tags, or remotes. However, it does _not_ recurse
into "sub-directories" to find a matching ref. It won't
recurse into forkee, unless you explicitly tell fetch to look
in forkee. With the old implementation you'd have to say
"refs/forkee/heads/something", while the new implementation
would also accept "forkee/heads/something".
Steffen
^ permalink raw reply
* Re: git help error
From: David Kastrup @ 2007-12-04 19:50 UTC (permalink / raw)
To: git
In-Reply-To: <20071204194754.GB30780@bit.office.eurotux.com>
Luciano Rocha <strange@nsk.no-ip.org> writes:
> On Tue, Dec 04, 2007 at 11:40:15AM -0800, Junio C Hamano wrote:
>
>> Having said that, I do not mind accepting a patch that prepends the
>> nonlocal path to MANPATH in help.c::show_man_page().
>
> Actually, current man utilities locate the manual page by looking where
> the executable is, if MANPATH isn't defined (tested in Linux and
> Darwin).
>
> So, "unset MANPATH; man git-add" should be sufficient.
That only works for paths registered in /etc/manpath.config (or an
equivalent config file depending on system/distribution).
--
David Kastrup
^ permalink raw reply
* Re: git help error
From: Luciano Rocha @ 2007-12-04 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sergei Organov, Aneesh Kumar, Git Mailing List
In-Reply-To: <7vr6i245b4.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]
On Tue, Dec 04, 2007 at 11:40:15AM -0800, Junio C Hamano wrote:
> Sergei Organov <osv@javad.com> writes:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> >> "Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
> >>
> >>> git help gives me the below error.
> >>>
> >>> [master@git]$ git help add
> >>> No manual entry for git-add
> >>> See 'man 7 undocumented' for help when manual pages are not available.
> >>> [master@git]$
> >>>
> >>> I have the git binaries installed via --prefix
> >>>
> >>> ./configure --prefix=/home/kvaneesh/bin-local/git/
> >>> and to see the man page i have to say
> >>>
> >>> man -M /home/kvaneesh/bin-local/git/share/man/
> >> ...
> >> When you run "man" from the command line, can you say
> >>
> >> $ man git-add
> >>
> >> and make it work? If it fails the same way, then what you are missing
> >> is MANPATH environment variable, isn't it?
> >
> > I think what the OP asked for makes sense. git-help should better find
> > corresponding version of manual pages automatically. This way, if one
> > invokes different versions of git-help, he will get corresponding
> > version of help text.
>
> I do not necessarily agree. Read what Aneesh wrote originally again,
> and read what he _didn't_ write.
>
> Not only he needs to run his "man" with -M (and my point was that it is
> not the only way, by the way), he needs to futz with his $PATH to
> include $HOME/bin-local/git for _his_ installation to work.
>
> I think my suggestion to use $MANPATH is in line with what he is already
> doing. If you install things in non-standard places, you can use
> environments to adjust to what you did, and that's the reason PATH and
> MANPATH environments are supported by your tools.
>
> Having said that, I do not mind accepting a patch that prepends the
> nonlocal path to MANPATH in help.c::show_man_page().
Actually, current man utilities locate the manual page by looking where
the executable is, if MANPATH isn't defined (tested in Linux and
Darwin).
So, "unset MANPATH; man git-add" should be sufficient.
--
lfr
0/0
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git help error
From: Junio C Hamano @ 2007-12-04 19:40 UTC (permalink / raw)
To: Sergei Organov; +Cc: Aneesh Kumar, Git Mailing List
In-Reply-To: <874pey9uow.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>> "Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
>>
>>> git help gives me the below error.
>>>
>>> [master@git]$ git help add
>>> No manual entry for git-add
>>> See 'man 7 undocumented' for help when manual pages are not available.
>>> [master@git]$
>>>
>>> I have the git binaries installed via --prefix
>>>
>>> ./configure --prefix=/home/kvaneesh/bin-local/git/
>>> and to see the man page i have to say
>>>
>>> man -M /home/kvaneesh/bin-local/git/share/man/
>> ...
>> When you run "man" from the command line, can you say
>>
>> $ man git-add
>>
>> and make it work? If it fails the same way, then what you are missing
>> is MANPATH environment variable, isn't it?
>
> I think what the OP asked for makes sense. git-help should better find
> corresponding version of manual pages automatically. This way, if one
> invokes different versions of git-help, he will get corresponding
> version of help text.
I do not necessarily agree. Read what Aneesh wrote originally again,
and read what he _didn't_ write.
Not only he needs to run his "man" with -M (and my point was that it is
not the only way, by the way), he needs to futz with his $PATH to
include $HOME/bin-local/git for _his_ installation to work.
I think my suggestion to use $MANPATH is in line with what he is already
doing. If you install things in non-standard places, you can use
environments to adjust to what you did, and that's the reason PATH and
MANPATH environments are supported by your tools.
Having said that, I do not mind accepting a patch that prepends the
nonlocal path to MANPATH in help.c::show_man_page().
^ permalink raw reply
* Cosmetic git-am interactive bug
From: Jeff Garzik @ 2007-12-04 19:19 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 999 bytes --]
Just now, I was exploring git-am's interactive mode, so as to comply
with Linus's urgings of a cleaner changelog <grin>. I had a raw email
changelog with the subject
Re: 2.6.24-rc3-git6: Reported regressions from 2.6.23
I used the [e]dit feature of interactive mode to change this
first-line/one-line summary to
pata_amd/pata_via: de-couple programming of PIO/MWDMA and UDMA
timings
When I hit [y]es to apply the patch, git reported
Applying 2.6.24-rc3-git6: Reported regressions from 2.6.23
Wrote tree 34cebd48e3b4e90fe3e6a6c6c03154ae1ed0c827
Committed: 943547abdfe9b4e27e36a25987909619908dffbf
The use of the older one-line summary led me to believe that it had not
committed my changelog edits. Looking at the result, however, proved
that the commit changelog was my new, corrected version.
Thus, I concluded that the printing of the old-and-no-longer-valid
changelog during the commit-to-tree phase was a bug.
Please see attached file for full example.
Thanks,
Jeff
[-- Attachment #2: git-am.txt --]
[-- Type: text/plain, Size: 3166 bytes --]
[jgarzik@pretzel libata-dev]$ git-am --utf8 --signoff -i /g/tmp/mbox
Commit Body is:
--------------------------
2.6.24-rc3-git6: Reported regressions from 2.6.23
On Saturday 01 December 2007, Rafael J. Wysocki wrote:
> Subject : 2.6.24-rc1: pata_amd fails to detect 80-pin wire
> Submitter : "Thomas Lindroth" <thomas.lindroth@gmail.com>
> References : http://lkml.org/lkml/2007/11/7/152
> http://bugzilla.kernel.org/show_bug.cgi?id=9322
> Handled-By : Tejun Heo <htejun@gmail.com>
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Patch : http://lkml.org/lkml/2007/11/11/115
Tejun's rework of cable detection code which fixes the problem has
been just applied into "upstream" (not "upstream-fixes") so it is
destined for 2.6.25 (I wasn't on cc: BTW) and since I got no feedback
on my patch (below) which also happens to fix the regression, was
acked by Alan, tested by Thomas and has been in -mm for 3 weeks now
I assume that everybody is happy with it (Jeff/Tejun: you were also
on cc: when the patch was merged into -mm)...
Linus, please apply.
[PATCH] pata_amd/pata_via: de-couple programming of PIO/MWDMA and UDMA timings
* Don't program UDMA timings when programming PIO or MWDMA modes.
This has also a nice side-effect of fixing regression added by commit
681c80b5d96076f447e8101ac4325c82d8dce508 ("libata: correct handling of
SRST reset sequences") (->set_piomode method for PIO0 is called before
->cable_detect method which checks UDMA timings to get the cable type).
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Tested-by: "Thomas Lindroth" <thomas.lindroth@gmail.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Tejun Heo <htejun@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
--------------------------
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all e
Commit Body is:
--------------------------
pata_amd/pata_via: de-couple programming of PIO/MWDMA and UDMA timings
* Don't program UDMA timings when programming PIO or MWDMA modes.
This has also a nice side-effect of fixing regression added by commit
681c80b5d96076f447e8101ac4325c82d8dce508 ("libata: correct handling of
SRST reset sequences") (->set_piomode method for PIO0 is called before
->cable_detect method which checks UDMA timings to get the cable type).
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Tested-by: "Thomas Lindroth" <thomas.lindroth@gmail.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Tejun Heo <htejun@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
--------------------------
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y
Applying 2.6.24-rc3-git6: Reported regressions from 2.6.23
Wrote tree 34cebd48e3b4e90fe3e6a6c6c03154ae1ed0c827
Committed: 943547abdfe9b4e27e36a25987909619908dffbf
^ permalink raw reply
* Re: git help error
From: Sergei Organov @ 2007-12-04 18:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aneesh Kumar, Git Mailing List
In-Reply-To: <7v1wa25oqc.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
>
>> git help gives me the below error.
>>
>> [master@git]$ git help add
>> No manual entry for git-add
>> See 'man 7 undocumented' for help when manual pages are not available.
>> [master@git]$
>>
>> I have the git binaries installed via --prefix
>>
>> ./configure --prefix=/home/kvaneesh/bin-local/git/
>> and to see the man page i have to say
>>
>> man -M /home/kvaneesh/bin-local/git/share/man/
>>
>> I guess git-help need to take care of the prefix.
>
> When you run "man" from the command line, can you say
>
> $ man git-add
>
> and make it work? If it fails the same way, then what you are missing
> is MANPATH environment variable, isn't it?
I think what the OP asked for makes sense. git-help should better find
corresponding version of manual pages automatically. This way, if one
invokes different versions of git-help, he will get corresponding
version of help text.
--
Sergei.
^ permalink raw reply
* Re: Not a valid object name refs/heads/t20050127-arm during git-cvsimport
From: Jakub Narebski @ 2007-12-04 18:06 UTC (permalink / raw)
To: Baurzhan Ismagulov; +Cc: git
In-Reply-To: <20071204171833.GD29315@radix50.net>
Baurzhan Ismagulov <ibr@radix50.net> writes:
> I want to import a CVS repo myrepo into git. I copied CVSHEAD and myrepo
> dirs from the cvs server to /home/ibr/tmp and issued the following
> command:
>
> git-cvsimport -p x -k -o cvshead -d/home/ibr/tmp -C zzz myrepo/drv
>
> It fails [...]
You can try to use other CVS importers, for example parsecvs from
Freedesktop project; see InterfaceFrontendsAndTools page on git wiki:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
--
Jakub Narebski
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: Junio C Hamano @ 2007-12-04 18:05 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Johannes Schindelin, Andreas Ericsson, git, Sam Vilain
In-Reply-To: <20071204155655.053f4fb4@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> On Tue, 4 Dec 2007 15:39:47 +0000 (GMT), Johannes Schindelin
> ...
> I found it! unset returns false
> ...
> I must leave now.
Thanks, you two.
I do not see "unset VAR... &&" outside t0001 test, but there are
instances of "unset VAR... &&" in git-submodule implementations as well.
In short, not too many places to fix.
^ permalink raw reply
* Re: [PATCH] Include diff options in the git-log manpage
From: Junio C Hamano @ 2007-12-04 17:57 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20071204122859.GQ31750@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Thu, Nov 01, 2007 at 03:57:40PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> Recently I wanted to see what git log -M does but actually I was not able to
>> find it in the manpage, finally figured out that all the diff options are
>> missing from here.
>>
>> Removing -p as it's already in diff-options.txt.
>
> could you please have a look at this patch? this also fixes the "-C is
> missing from man git-log" issue which was reported on IRC today.
There was a patch around diff options documentation from Sergei
last month, and somehow I thought it covered this issue as well.
Will format the docs before and after your fix, compare them, and then
decide either to drop or accept, which will take some time but will be
done before -rc0.
Thanks.
^ permalink raw reply
* Re: git help error
From: Junio C Hamano @ 2007-12-04 17:55 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <cc723f590712040826o7ca36bfg35b8cb4d64ee8d2d@mail.gmail.com>
"Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
> git help gives me the below error.
>
> [master@git]$ git help add
> No manual entry for git-add
> See 'man 7 undocumented' for help when manual pages are not available.
> [master@git]$
>
> I have the git binaries installed via --prefix
>
> ./configure --prefix=/home/kvaneesh/bin-local/git/
> and to see the man page i have to say
>
> man -M /home/kvaneesh/bin-local/git/share/man/
>
> I guess git-help need to take care of the prefix.
When you run "man" from the command line, can you say
$ man git-add
and make it work? If it fails the same way, then what you are missing
is MANPATH environment variable, isn't it?
^ permalink raw reply
* Re: [PATCH] Set OLD_ICONV on Cygwin.
From: Junio C Hamano @ 2007-12-04 17:54 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pascal Obry, Pascal Obry, Pascal Obry, git
In-Reply-To: <4755597B.9050709@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Nice. If my suspicions are correct and he missed your patch the first time
> around, you should probably resend it though.
I still have it in my mailbox.
I saw the patch but saw nobody else said about the patch being helpful
to his installation, nor more importantly, "Good, this won't hurt for me
who run a different vintage of Cygwin", and I was waiting for such
confirmations.
Then nobody responded, so I forgot.
That was what happened the first time Pascal's patch was posted.
^ permalink raw reply
* Re: git-add--interactive works only in top level
From: Junio C Hamano @ 2007-12-04 17:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Wincent Colaiuta, Reid Barton, git
In-Reply-To: <Pine.LNX.4.64.0712041148310.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Here he have two options: blame the user for his/her stupidity, or look
>> at this a UI problem and try to make the UI "idiot proof".
>>
>> In this particular case I see no impediment to favouring the second
>> option, because we're not talking about making changes that would make
>> Git less powerful or useful for "non-idiots", "power users" or "real
>> men" (whatever you want to call them). In other words, we are not
>> talking about "dumbing down" Git for the sake of the ignorant. This is
>> an opportunity to polish the UI in the same way that we polish the
>> internal pack format.
>
> You know, without patches you will not convince me ;-)
Honestly, I do not want a patch for that to git-add--interactive.
Once WIncent's and Dan's UI enhancements to it becomes stable (not
implementation-wise but more interface- and user-experience-wise),
rewriting it in C should not be too much of a hassle. When that
happens, it won't be a standalone program but will be a function
builtin-add.c::interactive_add() will call into and we won't have this
problem at that point. If somebody does do a patch, the time is better
spent there instead.
^ permalink raw reply
* Re: [PATCH] t9600: require cvsps 2.1 to perform tests
From: Junio C Hamano @ 2007-12-04 17:39 UTC (permalink / raw)
To: Jeff King; +Cc: gitzilla, Johannes Schindelin, git
In-Reply-To: <20071204154454.GA2994@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Dec 03, 2007 at 09:37:54PM -0800, Junio C Hamano wrote:
>
>> I wonder if it is better to grep for ' [-A] ' instead, like:
>>
>> cvsps_supports_A=$(cvsps -h 2>&1 | sed -ne '/\[-A\]/p')
>> case "$cvsps_supports_A" in
>> '')
>> say 'skipping cvsimport tests, lacking cvsps that supports -A option'
>> test_done
>> exit
>> esac
>
> I am not too opposed to that, but I felt that checking the version was a
> little bit more future proof. I.e., I have no idea if it is only -A that
> we need, but I know that 2.1 works and prior to 2.1 doesn't.
You are right about "we may be depending on what 2.1 has other than
-A". Will apply as-is.
Thanks, both.
The primary reason I asked about '\[-A\]' was what will happen if
somebody uses 2.2.
^ permalink raw reply
* Not a valid object name refs/heads/t20050127-arm during git-cvsimport
From: Baurzhan Ismagulov @ 2007-12-04 17:18 UTC (permalink / raw)
To: git
Hello,
I want to import a CVS repo myrepo into git. I copied CVSHEAD and myrepo
dirs from the cvs server to /home/ibr/tmp and issued the following
command:
git-cvsimport -p x -k -o cvshead -d/home/ibr/tmp -C zzz myrepo/drv
It fails with the following messages:
Initialized empty Git repository in /home/ibr/tmp/zzz/.git/
fatal: Not a valid object name refs/heads/t20050127-arm
read-tree failed: 32768
t20050127-arm is a branch that exists not for all files under
myrepo/drv.
How can I import this repo?
I use git 1.5.3.6-1.1 from Debian unstable and cvsps 2.1-2 from Debian
stable on a Debian testing/unstable system.
Thanks in advance,
--
Baurzhan Ismagulov
http://www.kz-easy.com/
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: Johannes Schindelin @ 2007-12-04 16:28 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andreas Ericsson, git, Sam Vilain
In-Reply-To: <20071204155655.053f4fb4@pc09.procura.nl>
Hi,
On Tue, 4 Dec 2007, H.Merijn Brand wrote:
> I found it! unset returns false
Oh, wow! The question is now: how to deal with it (there are quite a few
unsets in the test scripts).
Is there a way to override "unset" with something like this:
unset_real () {
unset "$@"
}
unset () {
unset_real "$@"
true
}
?
Ciao,
Dscho
^ permalink raw reply
* git help error
From: Aneesh Kumar @ 2007-12-04 16:26 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
git help gives me the below error.
[master@git]$ git help add
No manual entry for git-add
See 'man 7 undocumented' for help when manual pages are not available.
[master@git]$
I have the git binaries installed via --prefix
./configure --prefix=/home/kvaneesh/bin-local/git/
and to see the man page i have to say
man -M /home/kvaneesh/bin-local/git/share/man/
I guess git-help need to take care of the prefix.
-aneesh
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Brian Downing @ 2007-12-04 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlwv6sxr.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 30, 2007 at 06:37:52PM -0800, Junio C Hamano wrote:
> * jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
> - Start preparing the API documents.
>
> The primary reason of this series is because I think we made the system
> a lot less approachable by losing hackability. Although we still have
> sample scripts in contrib/example for use of plumbing in scripts, they
> will not help aspiring git-hacker-wannabees when our primary attention
> has already shifted to moving things to C.
>
> This currently consists of mostly stubs, although I wrote about a few
> topics as examples.
One comment on this:
+sometype *ary;
+int nr;
+int alloc
+
+for (i = 0; i < nr; i++)
+ if (you like ary[i])
+ return;
+/* you did not like any existing one, so add one */
+ALLOC_GROW(ary, nr+1, alloc);
+ary[nr++] = value you like;
Shouldn't we be encouraging the use of size_t here? I don't know of a
64-bit platform off hand that has an 'int' that's actually 64 bits, so
encouraging this just seems like asking for 64-bit platform limitations
when arrays get over 2GB.
(Looking through the code it looks like there's a fair bit of using
'int' for array indices already, but I think it's probably best not to
perpetuate that.)
-bcd
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Linus Torvalds @ 2007-12-04 15:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Robin Rosenberg, Jeff King, Junio C Hamano, Anatol Pomozov, git
In-Reply-To: <Pine.LNX.4.64.0712041149440.27959@racer.site>
On Tue, 4 Dec 2007, Johannes Schindelin wrote:
>
> I do remember the hassles I went through with get_relative_cwd() until I
> broke down and used chdir() two times (ugly).
It really is a pretty heavy and complex operation in UNIX in general (and
open to various races too), which is why I'd generally suggest avoiding it
if you at all can.
The sad(?) part is, it's fairly trivial to do inside the Linux kernel (but
probably not in other operating systems - it's only because of our
superior dcache that we could do it). So a special system call would be no
problem at all. But obviously very unportable indeed.
Linus
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: H.Merijn Brand @ 2007-12-04 15:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, git, Sam Vilain
In-Reply-To: <Pine.LNX.4.64.0712041536180.27959@racer.site>
On Tue, 4 Dec 2007 15:39:47 +0000 (GMT), Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 4 Dec 2007, H.Merijn Brand wrote:
>
> > + + pwd
> > GIT_EXEC_PATH=/pro/3gl/LINUX/git-1.5.3.7/t/..
> > + + pwd
> > GIT_TEMPLATE_DIR=/pro/3gl/LINUX/git-1.5.3.7/t/../templates/blt
> > + GIT_CONFIG=.git/config
> > + export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG
> > + + pwd
> > + pwd
> > GITPERLLIB=/pro/3gl/LINUX/git-1.5.3.7/t/../perl/blib/lib:/pro/3gl/LINUX/git-1.5.3.7/t/../perl/blib/arch/auto/Git
> > + export GITPERLLIB
> > + test -d ../templates/blt
> > + test -x ../test-chmtime
> > + test=trash
> > + rm -fr trash
> > + test_create_repo trash
> > + cd trash
> > + + expr ./t0001-init.sh : .*/\(t[0-9]*\)-[^/]*$
> > this_test=t0001
> > + test_expect_success plain
> > (
> > unset GIT_DIR GIT_WORK_TREE &&
> > mkdir plain &&
> > cd plain &&
> > git init
> > ) &&
> > check_config plain/.git false unset
> >
> > * expecting success:
> > (
> > unset GIT_DIR GIT_WORK_TREE &&
> > mkdir plain &&
> > cd plain &&
> > git init
> > ) &&
> > check_config plain/.git false unset
> >
> > * FAIL 1: plain
> >
> > (
> > unset GIT_DIR GIT_WORK_TREE &&
> > mkdir plain &&
> > cd plain &&
> > git init
> > ) &&
> > check_config plain/.git false unset
>
> That's not good. The relevant part here reads:
I found it! unset returns false
/pro/3gl/LINUX/git-1.5.3.7/t 152 > sh t0001*.sh
* ok 1: plain
* ok 2: plain with GIT_WORK_TREE
* ok 3: plain bare
* ok 4: plain bare with GIT_WORK_TREE
* ok 5: GIT_DIR bare
* ok 6: GIT_DIR non-bare
* ok 7: GIT_DIR & GIT_WORK_TREE (1)
* ok 8: GIT_DIR & GIT_WORK_TREE (2)
* passed all 8 test(s)
--8<---
--- t0001-init.sh.org 2007-12-04 16:55:25 +0100
+++ t0001-init.sh 2007-12-04 16:52:37 +0100
@@ -25,7 +25,7 @@ check_config () {
test_expect_success 'plain' '
(
- unset GIT_DIR GIT_WORK_TREE &&
+ unset GIT_DIR GIT_WORK_TREE ;
mkdir plain &&
cd plain &&
git init
@@ -35,7 +35,7 @@ test_expect_success 'plain' '
test_expect_success 'plain with GIT_WORK_TREE' '
if (
- unset GIT_DIR &&
+ unset GIT_DIR ;
mkdir plain-wt &&
cd plain-wt &&
GIT_WORK_TREE=$(pwd) git init
@@ -48,7 +48,7 @@ test_expect_success 'plain with GIT_WORK
test_expect_success 'plain bare' '
(
- unset GIT_DIR GIT_WORK_TREE GIT_CONFIG &&
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG ;
mkdir plain-bare-1 &&
cd plain-bare-1 &&
git --bare init
@@ -58,7 +58,7 @@ test_expect_success 'plain bare' '
test_expect_success 'plain bare with GIT_WORK_TREE' '
if (
- unset GIT_DIR GIT_CONFIG &&
+ unset GIT_DIR GIT_CONFIG ;
mkdir plain-bare-2 &&
cd plain-bare-2 &&
GIT_WORK_TREE=$(pwd) git --bare init
@@ -72,7 +72,7 @@ test_expect_success 'plain bare with GIT
test_expect_success 'GIT_DIR bare' '
(
- unset GIT_CONFIG &&
+ unset GIT_CONFIG ;
mkdir git-dir-bare.git &&
GIT_DIR=git-dir-bare.git git init
) &&
@@ -82,7 +82,7 @@ test_expect_success 'GIT_DIR bare' '
test_expect_success 'GIT_DIR non-bare' '
(
- unset GIT_CONFIG &&
+ unset GIT_CONFIG ;
mkdir non-bare &&
cd non-bare &&
GIT_DIR=.git git init
@@ -93,7 +93,7 @@ test_expect_success 'GIT_DIR non-bare' '
test_expect_success 'GIT_DIR & GIT_WORK_TREE (1)' '
(
- unset GIT_CONFIG &&
+ unset GIT_CONFIG ;
mkdir git-dir-wt-1.git &&
GIT_WORK_TREE=$(pwd) GIT_DIR=git-dir-wt-1.git git init
) &&
@@ -103,7 +103,7 @@ test_expect_success 'GIT_DIR & GIT_WORK_
test_expect_success 'GIT_DIR & GIT_WORK_TREE (2)' '
if (
- unset GIT_CONFIG &&
+ unset GIT_CONFIG ;
mkdir git-dir-wt-2.git &&
GIT_WORK_TREE=$(pwd) GIT_DIR=git-dir-wt-2.git git --bare init
)
-->8---
I must leave now.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH] Use a strbuf for copying the command line for the reflog.
From: Kristian Høgsberg @ 2007-12-04 15:46 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1196753147-20073-1-git-send-email-krh@redhat.com>
Doh, I forgot -n to git-format-patch again for this two patch series.
Maybe git-format-patch should default to -n when there's more than one
patch? Anyway, it should have been:
[PATCH 1/2] Use a strbuf for copying the command line for the reflog.
[PATCH 2/2] Rewrite builtin-fetch option parsing to use parse_options().
cheers,
Kristian
^ 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