* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: Brian Foster @ 2012-01-23 9:20 UTC (permalink / raw)
To: git mailing list; +Cc: Sitaram Chamarty
In-Reply-To: <CAMK1S_gkZYpK3nrNMsnmFzi=tzjyEjVwOo_j4Z=d0hqjdF7r_w@mail.gmail.com>
On Friday 20 January 2012 23:50:23 Sitaram Chamarty wrote:
> On Fri, Jan 20, 2012 at 7:03 PM, Brian Foster <brian.foster@maxim-ic.com> wrote:
>[ ... ]
> > x---Y---y---y---y HEAD
> > /
> > ...--o---o---C---o---S
> > \
> > n---n---N---*---* other
> >
> > In a script, how can I determine commit Y is reachable
> > from the current HEAD ? [ ... ]
>
> I've been using 'git rev-list HEAD..Y'. If it produces any output,
> Y is not reachable from HEAD (there is something in Y that is not
> in HEAD).
What's interesting about this solution, at least
with GIT v1.7.6.1 (I haven't tried other versions),
is ‘git rev-list HEAD..Y’ does seem to work (if
there is any output, then Y is not reachable from
HEAD), but ‘git rev-list --quiet HEAD..Y’ does _not_
work (it seems to always(?) exit status 0).
I am probably misunderstanding ‘--quiet’, which the
man page cryptically describes as “... allow the
caller to test the exit status to see if a range
of objects is fully connected (or not).” What is
meant here by “fully connected” ?
cheers!
-blf-
--
Brian Foster
Principal MTS, Software | La Ciotat, France
Maxim Integrated Products | Web: http://www.maxim-ic.com/
^ permalink raw reply
* Re: [BUG ?] completion of stash name with git stash
From: Mathieu CLAVEL @ 2012-01-23 8:36 UTC (permalink / raw)
To: git
In-Reply-To: <87obtzlfuv.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast <at> student.ethz.ch> writes:
> Indeed, I compiled bash 3.1 and with that (and otherwise the same bashrc
> etc.) I can reproduce. Ditto for 4.0-rc1, which was the newest version
> in the repository where I found the bash source[1], so I couldn't
> bisect. Perhaps if you can hunt down something newer you could try to
> find the version where it starts working.
>
> [1] git://gitorious.org/bash/bash.git
>
Thanks, so it's not a git issue, but a problm with the bash version.
Regards,
Mathieu
^ permalink raw reply
* Test t9500 fails if Time::HiRes is missing
From: Hallvard Breien Furuseth @ 2012-01-23 5:39 UTC (permalink / raw)
To: git
In-Reply-To: <hbf.20120123rqzg@bombur.uio.no>
I wrote:
> Better add a comment about that, so it doesn't get re-reverted.
Perhaps I should follow my own advise...
> Or pacify the test and expect gitweb@RHEL-users to install the RPM:
--- git-1.7.9.rc2/t/gitweb-lib.sh~
+++ git-1.7.9.rc2/t/gitweb-lib.sh
@@ -113,4 +113,10 @@
test_done
}
+# RedHat has moved Time::HiRes out from core Perl to a separate package.
+perl -MTime::HiRes -e 0 >/dev/null 2>&1 || {
+ skip_all='skipping gitweb tests, Time::HiRes module not available'
+ test_done
+}
+
gitweb_init
--
Hallvard
^ permalink raw reply
* Test t9500 fails if Time::HiRes is missing
From: Hallvard Breien Furuseth @ 2012-01-23 4:50 UTC (permalink / raw)
To: git
t9500-gitweb-standalone-no-errors fails: Git 1.7.9.rc2/1.7.8.4, RHEL
6.2, Perl 5.10.1. Reverting 3962f1d756ab41c1d180e35483d1c8dffe51e0d1
fixes it. The commit expects Time::HiRes to be present, but RedHat
has split it out to a separate RPM perl-Time-HiRes. Better add a
comment about that, so it doesn't get re-reverted.
Or pacify the test and expect gitweb@RHEL-users to install the RPM:
--- git-1.7.9.rc2/t/gitweb-lib.sh~
+++ git-1.7.9.rc2/t/gitweb-lib.sh
@@ -113,4 +113,9 @@
test_done
}
+perl -MTime::HiRes -e 0 >/dev/null 2>&1 || {
+ skip_all='skipping gitweb tests, Time::HiRes module not available'
+ test_done
+}
+
gitweb_init
--
Hallvard
^ permalink raw reply
* Re: [linux.conf.au] VCS Interoperability
From: Scott Chacon @ 2012-01-23 0:43 UTC (permalink / raw)
To: Brian Gernhardt
Cc: david, Ramkumar Ramachandra, David Michael Barr, git,
Junio C Hamano, Jonathan Nieder, Dmitry Ivankov
In-Reply-To: <3BC64515-C4C0-4D32-97B0-8FFD14BB903C@silverinsanity.com>
Hey,
On Sun, Jan 22, 2012 at 3:33 PM, Brian Gernhardt
<benji@silverinsanity.com> wrote:
>
> On Jan 22, 2012, at 4:12 PM, david@lang.hm wrote:
>
>> On Sun, 22 Jan 2012, Ramkumar Ramachandra wrote:
>>
>>> 3. What are your thoughts on lib'ifying Git so that others can call
>>> into it using an API?
>>
>> This is something that everyone agrees would be a good thing. There have been many people who have started projects to do so, but they have all stalled.
>
> I believe libgit2 is still under active development.
>
> http://libgit2.github.com
>
Yes, GitHub alone actually has 2 full time employees and 1 contractor
who are entirely dedicated to the project. It also ships with the
GitHub for Mac product, so it's used in production by tens of
thousands every day. If any of you want to get involved, you can check
out the mailing list (libgit2@librelist.org) or (probably more
usefully) the GitHub project page:
https://github.com/libgit2/libgit2
Open tickets, contribute code, review PRs, etc.
Scott
^ permalink raw reply
* Re: [RFC/PATCH git-remote-bzr] Adapt to new semantics of remote-helper "import" command
From: Jonathan Nieder @ 2012-01-23 0:12 UTC (permalink / raw)
To: Jelmer Vernooij
Cc: Gabriel Filion, git, Sverre Rabbelier, Jeff King, David Barr,
Dmitry Ivankov
In-Reply-To: <4F1C9D4C.6090603@samba.org>
Jelmer Vernooij wrote:
> On 01/22/2012 06:46 AM, Jonathan Nieder wrote:
>> BTW, would you mind if I sent a patch to include git-remote-bzr in
>> git.git under contrib/?
>
> Please note that the bzr-git package, which provides git integration
> for bzr and vice versa, also includes a 'git-remote-bzr' command.
That's good to hear. Then there should be no need for git.git to have
its own helper.
Unfortunately, when I try to clone any repo, at the last step I get
Traceback (most recent call last):map 6/7
File "/usr/lib/git-core/git-remote-bzr", line 220, in <module>
commands[argv[0]](argv, shortname, remote_dir)
File "/usr/lib/git-core/git-remote-bzr", line 89, in cmd_list
for ref, git_sha1 in refs.as_dict().iteritems():
File "/usr/lib/python2.7/dist-packages/dulwich/repo.py", line 196, in as_dict
ret[key] = self[("%s/%s" % (base, key)).strip("/")]
File "/usr/lib/python2.7/dist-packages/dulwich/repo.py", line 267, in __getitem__
_, sha = self._follow(name)
File "/usr/lib/python2.7/dist-packages/dulwich/repo.py", line 249, in _follow
contents = self.read_ref(refname)
File "/usr/lib/python2.7/dist-packages/dulwich/repo.py", line 225, in read_ref
contents = self.read_loose_ref(refname)
File "/usr/lib/python2.7/dist-packages/bzrlib/plugins/git/refs.py", line 129, in read_loose_ref
tag_name = ref_to_tag_name(ref)
File "/usr/lib/python2.7/dist-packages/bzrlib/plugins/git/refs.py", line 89, in ref_to_tag_name
raise ValueError("unable to map ref %s back to tag name" % ref)
ValueError: unable to map ref refs/heads back to tag name
Will file a bug.
^ permalink raw reply
* Re: [RFC/PATCH git-remote-bzr] Adapt to new semantics of remote-helper "import" command
From: Jelmer Vernooij @ 2012-01-22 23:35 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Gabriel Filion, git, Simon Poirier, Sverre Rabbelier, Jeff King,
David Barr, Dmitry Ivankov
In-Reply-To: <20120122054657.GA25103@burratino>
On 01/22/2012 06:46 AM, Jonathan Nieder wrote:
> Git 1.7.7 (commit 9504bc9d, "transport-helper: change import
> semantics", 2011-07-16) incompatibly changed the interface of the
> "import" capability.
>
> Before, git would always send a single import command, which the
> remote helper would respond to with a fast-import stream, terminated
> by end of file, meaning there was no way to fetch multiple refs in one
> connection. Nowadays, git instead sends a sequence of import lines:
>
> import refs/heads/foo
> import refs/heads/bar
>
> terminated by a blank line. The helper is to respond with a
> fast-import stream terminated by the "done" command and process
> further commands until another blank line indicates the end of the
> command stream.
> ---
> Hi Simon and Gabriel,
>
> Here's a rough patch against git://github.com/lelutin/git-remote-bzr.git
> master.
>
> Without this patch, whenever I try to use "git clone bzr::<something>",
> after doing all the work it removes the resulting repo and exits with
> status 141 (SIGPIPE). Maybe the transport-helper should mask SIGPIPE
> when writing the final newline to avoid that.
>
> I'd have prefered to write a patch for remote-bzr that works with
> older versions of git fast-import, too, but it wasn't obvious how.
> Hints welcome.
>
> BTW, would you mind if I sent a patch to include git-remote-bzr in
> git.git under contrib/?
Please note that the bzr-git package, which provides git integration for
bzr and vice versa, also includes a 'git-remote-bzr' command. Apart from
the 'import' command, it includes experimental implementations of
'fetch' and push as well.
It would be nice to consolidate the efforts, or at the very least
prevent name clashes.
Cheers,
Jelmer
^ permalink raw reply
* Re: [linux.conf.au] VCS Interoperability
From: Brian Gernhardt @ 2012-01-22 23:33 UTC (permalink / raw)
To: david
Cc: Ramkumar Ramachandra, David Michael Barr, git, Junio C Hamano,
Jonathan Nieder, Dmitry Ivankov
In-Reply-To: <alpine.DEB.2.02.1201221310540.28747@asgard.lang.hm>
On Jan 22, 2012, at 4:12 PM, david@lang.hm wrote:
> On Sun, 22 Jan 2012, Ramkumar Ramachandra wrote:
>
>> 3. What are your thoughts on lib'ifying Git so that others can call
>> into it using an API?
>
> This is something that everyone agrees would be a good thing. There have been many people who have started projects to do so, but they have all stalled.
I believe libgit2 is still under active development.
http://libgit2.github.com
^ permalink raw reply
* Re: [PATCH] fix git-gui crash due to uninitialized variable
From: Pat Thoyts @ 2012-01-22 23:18 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <20120121175724.GA7319@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
>Recently, a clone initiated via git gui on Windows crashed on me due to
>an "unknown variable cdone". It turns out that there is a code path
>where this variable is used uninitialized.
>
>Signed-off-by: Clemens Buchacher <drizzd@aon.at>
>---
>
>Looking at the output of display(), it's not clear to me now the
>function below could ever be called with total=0. But I can't delve into
>it more deeply right now, and this seems like an obvious fix.
>
> git-gui/lib/status_bar.tcl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
>diff --git a/git-gui/lib/status_bar.tcl b/git-gui/lib/status_bar.tcl
>index 95cb449..02111a1 100644
>--- a/git-gui/lib/status_bar.tcl
>+++ b/git-gui/lib/status_bar.tcl
>@@ -77,6 +77,7 @@ method start {msg uds} {
>
> method update {have total} {
> set pdone 0
>+ set cdone 0
> if {$total > 0} {
> set pdone [expr {100 * $have / $total}]
> set cdone [expr {[winfo width $w_c] * $have / $total}]
It might be nice to know what kind of conditions triggered this for you,
but the patch is fine. Thanks, applied.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [linux.conf.au] VCS Interoperability
From: david @ 2012-01-22 21:12 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: David Michael Barr, git, Junio C Hamano, Jonathan Nieder,
Dmitry Ivankov
In-Reply-To: <CALkWK0nsO2EBLUrO_iWAdGYpULt=oug4yPDnczX9c44hzdwzqg@mail.gmail.com>
On Sun, 22 Jan 2012, Ramkumar Ramachandra wrote:
> 3. What are your thoughts on lib'ifying Git so that others can call
> into it using an API?
This is something that everyone agrees would be a good thing. There have
been many people who have started projects to do so, but they have all
stalled.
David Lang
^ permalink raw reply
* Re: [PATCH] t/Makefile: Use $(sort ...) explicitly where needed
From: Kirill Smelkov @ 2012-01-22 19:17 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Junio C Hamano, git
In-Reply-To: <20120120071936.GA22112@mini.zxlink>
On Fri, Jan 20, 2012 at 11:19:36AM +0400, Kirill Smelkov wrote:
> On Thu, Jan 19, 2012 at 11:14:18PM -0800, Junio C Hamano wrote:
> > Kirill Smelkov <kirr@navytux.spb.ru> writes:
> >
> > >> I do not necessarily buy your "so we HAVE TO, OR ELSE".
> > >>
> > >> Even though I can understand "We can sort the list of tests _if_ we do not
> > >> want them executed in seemingly random order when running 'make -j1'", I
> > >> tend to think that *if* is a big one. Aren't these tests designed not to
> > >> depend on each other anyway?
> > >
> > > Yes, they don't depend on each other, but what's the point in not
> > > sorting them? I usually watch test progress visually, and if tests are
> > > sorted, even with make -j4 they go more or less incrementally by their t
> > > number.
> > >
> > > On my netbook, adding $(sort ...) adds approximately 0.008s to make
> > > startup, so imho there is no performance penalty to adding that sort.
> >
> > Heh, who said anything about performance?
> >
> > I was pointing out that your justification "we HAVE TO" was wrong.
> >
> > If you are doing this for perceived prettyness and not as a fix for any
> > correctness issue, I want to see the patch honestly described as such;
> > that's all.
>
> I agree about rewording.
>
>
> > By the way, if I recall correctly, $(sort) in GNU make not just sorts but
> > as a nice side effect removes duplicates. So if we used a(n fictional)
> > construct in our Makefile like this:
> >
> > T = $(wildcard *.sh a.*)
> >
> > that might produce duplicates (i.e. "a.sh" might appear twice), which
> > might leave us two identical pathnames in $T and cause us trouble. Even
> > if we do not have such a use currently, rewriting $(wildcard) like your
> > patch does using $(sort $(wildcard ...)) may be a good way to future-proof
> > our Makefile, and if you justify your patch that way, it would be a
> > possible correctness hardening, not just cosmetics, and phrasing it with
> > "HAVE TO" may be justifiable.
> >
> > Care to try if $(wildcard *.sh a.*) give you duplicated output with newer
> > GNU make? I am lazy but am a bit curious ;-)
>
> Sure. Please give me time untill evening (GMT+0400), or maybe till the
> weekend.
Hello up there again. You are actually right about sort also working as uniq,
e.g. for the following Makefile
T := $(wildcard *.sh a.*)
$(info "T : $T")
$(info "sort(T): $(sort $T)")
$(error 1)
I'm getting duplicates for a.sh and $(sort) removes it
$ ls
0.sh a.sh b.sh c.sh Makefile
$ make -v |head -1
GNU Make 3.82.90
$ make # v v
"T : 0.sh c.sh a.sh b.sh a.sh"
"sort(T): 0.sh a.sh b.sh c.sh"
Makefile:4: *** 1. Stop.
BUT for older make the duplicate is there too:
$ /usr/bin/make -v | head -1
GNU Make 3.81 # this one has its base from 2006
$ /usr/bin/make # v v
"T : 0.sh a.sh b.sh c.sh a.sh"
"sort(T): 0.sh a.sh b.sh c.sh"
Makefile:4: *** 1. Stop.
so yes earlier $(wildcard) sorted the result and no, it sorted it not globally,
but separately for each pattern, so in presence of multiple pattern one could
not rely on implicit auto-uniq even for older make.
If we'd like to protect ourselves from duplicates, the sort should be there for
all makes.
Updated patch follows (sorry for my bad english, I'm too sleepy to get this
into shape even by mine standards...)
---- 8< ----
From: Kirill Smelkov <kirr@navytux.spb.ru>
Date: Sun, 4 Sep 2011 00:41:21 +0400
Subject: [PATCH] t/Makefile: Use $(sort ...) explicitly where needed
Starting from GNU Make 3.82 $(wildcard ...) no longer sorts the result
(from NEWS):
* WARNING: Backward-incompatibility!
Wildcards were not documented as returning sorted values, but the results
have been sorted up until this release.. If your makefiles require sorted
results from wildcard expansions, use the $(sort ...) function to request
it explicitly.
http://repo.or.cz/w/make.git/commitdiff/2a59dc32aaf0681dec569f32a9d7ab88a379d34f
I usually watch test progress visually, and if tests are sorted, even
with make -j4 they go more or less incrementally by their t number. On
the other side, without sorting, tests are executed in seemingly random
order even for -j1. Let's please maintain sane tests order for perceived
prettyness.
Another note is that in GNU Make sort also works as uniq, so after sort
being removed, we might expect e.g. $(wildcard *.sh a.*) to produce
duplicates for e.g. "a.sh". From this point of view, adding sort could
be seen as hardening t/Makefile from accidentally introduced dups.
It turned out that prevous releases of GNU Make did not perform full
sort in $(wildcard), only sorting results for each pattern, that's why
explicit sort-as-uniq is relevant even for older makes.
Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru>
---
t/Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/Makefile b/t/Makefile
index 9046ec9..66ceefe 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -17,9 +17,9 @@ DEFAULT_TEST_TARGET ?= test
# Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
-T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
-TSVN = $(wildcard t91[0-9][0-9]-*.sh)
-TGITWEB = $(wildcard t95[0-9][0-9]-*.sh)
+T = $(sort $(wildcard t[0-9][0-9][0-9][0-9]-*.sh))
+TSVN = $(sort $(wildcard t91[0-9][0-9]-*.sh))
+TGITWEB = $(sort $(wildcard t95[0-9][0-9]-*.sh))
all: $(DEFAULT_TEST_TARGET)
--
1.7.9.rc2.124.ge3180
^ permalink raw reply related
* Re: What does "modified" in git status mean?
From: Seth Robertson @ 2012-01-22 17:56 UTC (permalink / raw)
To: Mikolas; +Cc: git
In-Reply-To: <loom.20120122T174204-274@post.gmane.org>
In message <loom.20120122T174204-274@post.gmane.org>, Mikolas writes:
1) Is there some way how to tell status to tell me *why* the files
are marked as modified?
Not as such. However, I do have a script which, when run from the
root of the working directory, manually compares the on-disk files to
what is checked into git. This would detect any whitespace or smudge
related changes, or of course any normal user changes.
git ls-tree --name-only -r HEAD | while read path; do if [ ! -f "$path" ]; then continue; fi; sha1=`git show "HEAD:$path" | sha1sum | awk '{print $1;}'`; sha2=`sha1sum "$path" | awk '{print $1;}'`; if [ $sha1 != $sha2 ]; then echo "<$sha1> <$sha2> $path"; fi; done
2) Is it normal that git status behaves differently in different directories?
I would say not, but perhaps you have a .gitattributes in that
directory? (Which would be a bug) Could you try with a more recent
version of git?
-Seth Robertson
^ permalink raw reply
* Re: Checkout tag?
From: Magnus Bäck @ 2012-01-22 17:33 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Magnus Bäck, Abscissa, git, Jakub Narebski,
Nguyen Thai Ngoc Duy
In-Reply-To: <20120122170800.GA29215@burratino>
On Sunday, January 22, 2012 at 18:08 CET,
Jonathan Nieder <jrnieder@gmail.com> wrote:
> Magnus Bäck wrote:
>
> > Looking at an up to date Git 1.7.9-rc2 man page, it still seems
> > slightly inconsistent with itself. The synopsis at the top says
> >
> > git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
> >
> > while the text in the DESCRIPTION section says
> >
> > git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
>
> Hmm, my copy says:
>
> SYNOPSIS
>
> git checkout [-q] [-f] [-m] [<branch>]
> git checkout [-q] [-f] [-m] [--detach] [<commit>]
> git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
> git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
> git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
Perhaps I wasn't clear -- I didn't mean that the synopsis *only* listed
the form in my original quote above.
> DESCRIPTION
>
> ... overview ...
>
> git checkout [<branch>], git checkout -b|-B <new_branch> [<start point>],
> git checkout [--detach] [<commit>]
>
> This form switches branches by updating the index, working
> tree, and HEAD...
>
> git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
>
> When <paths> or --patch are given, git checkout does not
> switch branches. It updates the named paths...
>
> So in the synopsis it lists five forms, and in the description section
> it lists two forms, the first of which has three variants.
>
> It's not immediately obvious to me which inconsistency you are
> pointing to as a source of confusion. Could you elaborate,
> preferably with suggested wording for a fix?
I simply meant that
git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
aren't identical even though I assume they describe the exact same
scenario. The first command synopsis makes it clear that paths are
optional while the second indicates that at least one path must be
specified (unless "..." means "zero, one, or more occurences").
Also, "paths" != "pathspec".
> If you can do so in the form of a patch, all the better. ;-)
Sure, but it won't be during the coming week. Not that the patch is
terribly difficult to prepare but because I need legal approval to
submit it, and it's not clear I'll have time to deal with all that
during my last week at work.
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ permalink raw reply
* What does "modified" in git status mean?
From: Mikolas @ 2012-01-22 16:57 UTC (permalink / raw)
To: git
I am using git version 1.7.5.1 under cygwin and I'm getting behavior that I'm
not understanding.
When I do 'git status' in the root directory of the repository, it shows no
difference. Once I cd to a subdirectory, it starts showing modifications.
However, 'git diff' shows nothing.
So it looks something like this:
$ git status
# On branch master
nothing to commit (working directory clean)
$ cd foo
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: ../foo/bar
$ git diff
$
I put the following in my gitconfig but that doesn't seem to be doing much.
[core]
trustctime = false
autocrlf = input
So my questions are
1) Is there some way how to tell status to tell me *why* the files are marked
as modified?
2) Is it normal that git status behaves differently in different directories?
--mikolas
^ permalink raw reply
* Re: Checkout tag?
From: Jonathan Nieder @ 2012-01-22 17:08 UTC (permalink / raw)
To: Magnus Bäck; +Cc: Abscissa, git, Jakub Narebski, Nguyen Thai Ngoc Duy
In-Reply-To: <20120122113115.GA31545@jpl.local>
Hi,
Magnus Bäck wrote:
> Looking at an up to date Git 1.7.9-rc2 man page, it still seems
> slightly inconsistent with itself. The synopsis at the top says
>
> git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
>
> while the text in the DESCRIPTION section says
>
> git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
Hmm, my copy says:
SYNOPSIS
git checkout [-q] [-f] [-m] [<branch>]
git checkout [-q] [-f] [-m] [--detach] [<commit>]
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
DESCRIPTION
... overview ...
git checkout [<branch>], git checkout -b|-B <new_branch> [<start point>],
git checkout [--detach] [<commit>]
This form switches branches by updating the index, working
tree, and HEAD...
git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
When <paths> or --patch are given, git checkout does not
switch branches. It updates the named paths...
So in the synopsis it lists five forms, and in the description section
it lists two forms, the first of which has three variants.
It's not immediately obvious to me which inconsistency you are
pointing to as a source of confusion. Could you elaborate, preferably
with suggested wording for a fix? If you can do so in the form of a
patch, all the better. ;-)
Thanks,
Jonathan
^ permalink raw reply
* Re: Including git-describe info as version strings for generic "-v" output
From: Dirk Süsserott @ 2012-01-22 16:03 UTC (permalink / raw)
To: Harry portobello; +Cc: Junio C Hamano, git
In-Reply-To: <7vd3acbtn3.fsf@alter.siamese.dyndns.org>
Am 21.01.2012 23:03 schrieb Junio C Hamano:
> Harry portobello <harryportobello@gmail.com> writes:
>
>> I hope the subject makes sense -- I'll explain what I'm trying to do.
>
> Perhaps take a look at GIT-VERSION-GEN that is part of the Git source?
At work, we have the same "problem". I solved it like so:
version.h:
----------------------------------------------
#ifndef __version_h__
#define __version_h__
#ifdef __cplusplus
extern "C" {
#endif
/*
* Returns a version string as defined with the -D compiler switch.
*/
char const * software_version();
#ifdef __cplusplus
}
#endif
#endif
----------------------------------------------
version.c:
----------------------------------------------
#include "version.h"
char const * software_version()
{
return SW_VERSION;
}
----------------------------------------------
And then make sure that ONLY version.c gets compiled like this:
gcc -DSW_VERSION=\"$(git describe --dirty)\" \
[other options] \
-c version.c -o version.o
Actually I use Scons to build my software (not Make). Scons
automatically keeps track of dependencies and changed compiler switches
between its runs. Thus it will re-compile version.c if the output of
git-describe changes. That's why Scons users must make sure that the
-D-switch is given only to version.c (else Scons would re-compile ALL
files because of the different argument to -D).
If you are using Make then make sure that version.c gets compiled
always. The drawback is that your app will be re-linked with every
single Make run.
That's why I prefer Scons: it calculates the dependencies on a checksum
basis. If the *contents* of version.c together with the compiler options
didn't change, it won't re-compile it. Furtermore: if the *contents* of
version.o didn't change, it won't re-link. Timestamps don't matter to
Scons. But that's another topic :-)
HTH
Dirk
^ permalink raw reply
* Re: Checkout tag?
From: Magnus Bäck @ 2012-01-22 11:31 UTC (permalink / raw)
To: Abscissa; +Cc: git
In-Reply-To: <1327227956026-7213061.post@n2.nabble.com>
On Sunday, January 22, 2012 at 11:25 CET,
Abscissa <bus_nabble_git@semitwist.com> wrote:
> I saw that, but it seems to imply that it's not a simple:
>
> >git checkout tag_name
>
> because of the required <pathspec>, whatever that is.
It isn't required. The part of the manual that I quoted (from Git
1.7.2.5) indicated that the pathspec is mandatory, but looking at
the command synopsis at the top of the man page it's actually listed
as optional.
Looking at an up to date Git 1.7.9-rc2 man page, it still seems
slightly inconsistent with itself. The synopsis at the top says
git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
while the text in the DESCRIPTION section says
git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
The DETACHED HEAD section of the man page contains an example of
checking out a tag, by the way.
If you're doubtful, why don't you just create a tag and try things
out for yourself?
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ permalink raw reply
* Re: Checkout tag?
From: Jakub Narebski @ 2012-01-22 11:30 UTC (permalink / raw)
To: Magnus Bäck; +Cc: Abscissa, git
In-Reply-To: <20120122101116.GA31022@jpl.local>
Magnus Bäck <magnus.back@sonyericsson.com> writes:
> On Sunday, January 22, 2012 at 11:05 CET,
> Abscissa <bus_nabble_git@semitwist.com> wrote:
>
> > I've managed to figure out you switch branches with the checkout
> > command, like this:
> >
> > $ git checkout branch_name
> >
> > Does that work for tags as well? The docs don't seem clear on that.
> > If not, how do you get the working copy to be a specific tag?
>
> Yes, "git checkout" works for branches, tags, commit SHA-1s, and
> anything else that can be resolved to a SHA-1 identifying what to
> check out. [...]
Note however that because you can generate new commits only on top of
local branches (refs/heads/*), if you check out something other than
local branch, e.g.:
$ git checkout v1.7.8
$ git checkout origin/next
$ git checkout HEAD^
you would be after such checkout in unnamed anonymous branch which
contents corresponds to what you checked out. This state is called
'detached HEAD', and shows e.g. in "git branch output as
$ git branch
* (no branch)
master
...
On the other hand if you don't want to checkout tag to explore it, but
set contents of working area to the state it was in given tag, you can
use
$ git checkout v1.7.8 -- .
HTH
P.S. Instead of Nabble you can use GMane interface, or just use email
(you don't have ot be subscribed to git@vger.kernel.org to post, and
it is custom here to send replies also to author(s)).
--
Jakub Narebski
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:34 UTC (permalink / raw)
To: git
In-Reply-To: <1327228177859-7213081.post@n2.nabble.com>
Sorry for the duplicates. Nabble kept crashing every time I tried to post,
but I guess it was crashing after it posted to the mailing list.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213090.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:29 UTC (permalink / raw)
To: git
In-Reply-To: <CACsJy8AUaJ_tkLSHYPZEPLuiNitRMS77b7n9JFeV6HABHj9Qiw@mail.gmail.com>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213081.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:29 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213078.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:28 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213076.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:28 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213074.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:27 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213072.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:27 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213069.html
Sent from the git mailing list archive at Nabble.com.
^ 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