* 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: 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: 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
* 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: 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
* 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: [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: [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] 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: 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: [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: [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: [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
* 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
* 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
* 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
* 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
* [PATCH] Don't search files with an unset "grep" attribute
From: conrad.irwin @ 2012-01-23 9:37 UTC (permalink / raw)
To: git; +Cc: Nguyen Thai Ngoc Duy, Conrad Irwin, Junio C Hamano, Dov Grobgeld
In-Reply-To: <CACsJy8C0aXgecCWHrCK3yzNLWnWX4g81x-OzZCY0xtonbspzXw@mail.gmail.com>
From: Conrad Irwin <conrad.irwin@gmail.com>
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
> Definitely. But because I'm stuck at adding "seen" feature from
> match_pathspec_depth to tree_entry_interesting, that probably won't happen
> this year. Adding "--exclude=<pattern>" to git-grep is a more plausible
> option.
I think the .gitattributes mechanism is a better place to configure this, as the
files I with to exclude from grep are always the same files (test fixtures
mainly, minified library code also). I often want to make git-diff be quieter
about them too, so I'll be setting the -diff attribute already.
I've attached a patch, which adds the "grep" attribute, which can (for now) only
be unset. This has the same effect for me as my original patch [1], but should
also improve life for people with large blobs as described above.
In future we could extend the attribute to give a meaning to set values, but I'm
not yet sure what that would look like. We could also add an --exclude=<foo>
flag to grep for people who want to configure grep on a per-run basis, but I
think that is a much less common desire.
The failing test attached to this patch is a symptom of a larger issue with the
way that git-grep handles objects that are not at the root of the repository. A
more obvious symptom can be revealed by comparing the output of:
git grep int HEAD:./builtin
cd builtin; git grep int HEAD:./
The problem is that grep doesn't correctly separate the path from the revision
part of the spec. It's currently unobvious to me how to fix this but I hope
someone more familiar with the code (Nguyen or Junio) might be able to see a
way.
Yours,
Conrad
[1] http://thread.gmane.org/gmane.comp.version-control.git/179299
---8<---
To set -grep on an file in .gitattributes will cause that file to be
skipped completely while grepping. This can be used to reduce the number
of false positives when your repository contains files that are
uninteresting to you, for example test fixtures, dlls or minified source
code.
The other approach considered was to allow an --exclude flag to grep at runtime,
however that better serves the less common use-case of wanting to customise the
list of files per-invocation rather than statically.
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
---
Documentation/git-grep.txt | 7 +++++++
Documentation/gitattributes.txt | 9 +++++++++
builtin/grep.c | 8 ++++++++
grep.c | 21 +++++++++++++++++++++
grep.h | 1 +
t/t7810-grep.sh | 30 ++++++++++++++++++++++++++++++
6 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 6a8b1e3..7c74165 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -242,6 +242,13 @@ OPTIONS
If given, limit the search to paths matching at least one pattern.
Both leading paths match and glob(7) patterns are supported.
+ATTRIBUTES
+----------
+
+grep::
+ If the grep attribute is unset on a file using the linkgit:gitattributes[1]
+ mechanism, then that file will not be searched.
+
Examples
--------
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index a85b187..3ffcec7 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -869,6 +869,15 @@ If this attribute is not set or has an invalid value, the value of the
`gui.encoding` configuration variable is used instead
(See linkgit:git-config[1]).
+Configuring files to search
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`grep`
+^^^^^^
+
+If the attribute `grep` is unset for a file then linkgit:git-grep[1]
+will ignore that file while searching for matches.
+
USING MACRO ATTRIBUTES
----------------------
diff --git a/builtin/grep.c b/builtin/grep.c
index 9ce064a..9f8dfc0 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -398,6 +398,10 @@ static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1,
struct strbuf pathbuf = STRBUF_INIT;
char *name;
+ if (!should_grep_path(opt, filename + tree_name_len)) {
+ return 0;
+ }
+
if (opt->relative && opt->prefix_length) {
quote_path_relative(filename + tree_name_len, -1, &pathbuf,
opt->prefix);
@@ -464,6 +468,10 @@ static int grep_file(struct grep_opt *opt, const char *filename)
struct strbuf buf = STRBUF_INIT;
char *name;
+ if (!should_grep_path(opt, filename)) {
+ return 0;
+ }
+
if (opt->relative && opt->prefix_length)
quote_path_relative(filename, -1, &buf, opt->prefix);
else
diff --git a/grep.c b/grep.c
index 486230b..e948576 100644
--- a/grep.c
+++ b/grep.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "grep.h"
+#include "attr.h"
#include "userdiff.h"
#include "xdiff-interface.h"
@@ -829,6 +830,26 @@ static inline void grep_attr_unlock(struct grep_opt *opt)
#define grep_attr_unlock(opt)
#endif
+static struct git_attr_check attr_check[1];
+static void setup_attr_check(void)
+{
+ if (attr_check[0].attr)
+ return; /* already done */
+ attr_check[0].attr = git_attr("grep");
+}
+int should_grep_path(struct grep_opt *opt, const char *name) {
+ int ret = 1;
+
+ grep_attr_lock(opt);
+ setup_attr_check();
+ git_check_attr(name, 1, attr_check);
+ if (ATTR_FALSE(attr_check[0].value))
+ ret = 0;
+ grep_attr_unlock(opt);
+
+ return ret;
+}
+
static int match_funcname(struct grep_opt *opt, const char *name, char *bol, char *eol)
{
xdemitconf_t *xecfg = opt->priv;
diff --git a/grep.h b/grep.h
index fb205f3..266002d 100644
--- a/grep.h
+++ b/grep.h
@@ -129,6 +129,7 @@ extern void append_header_grep_pattern(struct grep_opt *, enum grep_header_field
extern void compile_grep_patterns(struct grep_opt *opt);
extern void free_grep_patterns(struct grep_opt *opt);
extern int grep_buffer(struct grep_opt *opt, const char *name, char *buf, unsigned long size);
+extern int should_grep_path(struct grep_opt *opt, const char *name);
extern struct grep_opt *grep_opt_dup(const struct grep_opt *opt);
extern int grep_threads_ok(const struct grep_opt *opt);
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 7ba5b16..c991518 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -871,4 +871,34 @@ test_expect_success 'mimic ack-grep --group' '
test_cmp expected actual
'
+test_expect_success 'with -grep attribute' '
+ echo "hello.c -grep" >.gitattributes &&
+ test_must_fail git grep printf &&
+ rm .gitattributes
+'
+
+test_expect_success 'with -grep attribute on specific file' '
+ echo "hello.c -grep" >.gitattributes &&
+ test_must_fail git grep printf hello.c &&
+ rm .gitattributes
+'
+
+test_expect_success 'with -grep attribute on specific revision' '
+ echo "hello.c -grep" >.gitattributes &&
+ test_must_fail git grep printf HEAD &&
+ rm .gitattributes
+'
+
+test_expect_success 'with -grep attribute on specific file/revision' '
+ echo "hello.c -grep" >.gitattributes &&
+ test_must_fail git grep printf HEAD hello.c &&
+ rm .gitattributes
+'
+
+test_expect_failure 'with -grep attribute on specific tree' '
+ echo "hello.c -grep" >.gitattributes &&
+ test_must_fail git grep printf HEAD:hello.c &&
+ rm .gitattributes
+'
+
test_done
--
1.7.9.rc2.1.g1fdd3
^ permalink raw reply related
* Re: Test t9500 fails if Time::HiRes is missing
From: Ævar Arnfjörð Bjarmason @ 2012-01-23 9:42 UTC (permalink / raw)
To: Hallvard Breien Furuseth; +Cc: git, Jakub Narebski
In-Reply-To: <hbf.20120123rqzg@bombur.uio.no>
On Mon, Jan 23, 2012 at 05:50, Hallvard Breien Furuseth
<h.b.furuseth@usit.uio.no> wrote:
> 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
[Adding Jakub to CC]
This doesn't actually fix the issue, it only sweeps it under the rug
by making the tests pass, gitweb will still fail to compile on Red
Hat once installed.
I think the right solution is to partially revert
3962f1d756ab41c1d180e35483d1c8dffe51e0d1, but add a comment in the
code indicating that it's to deal with RedHat's broken fork of Perl.
However even if it's required in an eval it might still fail at
runtime in the reset_timer() function, which'll need to deal with it
too.
^ permalink raw reply
* [BUG] incorrect error message in "git fsck" for empty loose objects
From: Matthieu Moy @ 2012-01-23 10:19 UTC (permalink / raw)
To: git; +Cc: Junio C. Hamano
Hi,
If a loose object is empty, "git fsck" reports it as corrupt (which is
good), but with the following error message:
$ git fsck
Checking object directories: 100% (256/256), done.
fatal: failed to read object c1738f6288c9e5d5e58da00ced34d284ae93976c: Invalid argument
$ cat .git/objects/c1/738f6288c9e5d5e58da00ced34d284ae93976c
$ ls -l .git/objects/c1/738f6288c9e5d5e58da00ced34d284ae93976c
-r--r--r-- 1 moy synchron 0 Jan 20 16:20 .git/objects/c1/738f6288c9e5d5e58da00ced34d284ae93976c
"Invalid argument" is really not the error message one would expect.
Before that, git used to say:
fatal: loose object c1738f6288c9e5d5e58da00ced34d284ae93976c (stored in
.git/objects/c1/738f6288c9e5d5e58da00ced34d28
4ae93976c) is corrupt
Which was far better.
This bisects back to 3ba7a065527a (A loose object is not corrupt if it
cannot be read due to EMFILE), which essentially boils down to:
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2090,16 +2090,21 @@ void *read_sha1_file_repl(const unsigned char *sha1,
const unsigned char **replacement)
[...]
+ errno = 0;
+ data = read_object(repl, type, size);
if (data) {
if (replacement)
*replacement = repl;
return data;
}
+ if (errno != ENOENT)
+ die_errno("failed to read object %s", sha1_to_hex(sha1));
+
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC/PATCH] git put: an alternative to add/reset/checkout
From: Nguyen Thai Ngoc Duy @ 2012-01-23 10:32 UTC (permalink / raw)
To: Jeff King
Cc: git, Scott Chacon, Michael Nahas, Jakub Narebski, Matthieu Moy,
Junio C Hamano
In-Reply-To: <20110607200659.GA6177@sigill.intra.peff.net>
(Bringing up an old thread)
On Wed, Jun 8, 2011 at 3:06 AM, Jeff King <peff@peff.net> wrote:
> ...
> But another way to think about it is that commits, the index, and the
> working tree are all "locations" with content. And one common operation
> you may want to do is to move content from one spot to another, either
> whole, by file, or by diff hunks. To a new user, knowing that "add" is
> the command for moving content from thet working tree to the index does
> not help them know which command to use to do the opposite content
> movement.
> ...
> My idea is therefore to have a single command for moving content from
> one location to another. You specify a source and a destination and get
> a uniform interface for moving content.
>
> A proof-of-concept patch is below. Be aware that is meant to be
> illustrative and is not well tested. Also, it is a minimal presentation
> of the concept. Other "locations" may also be meaningful. I'll include
> some ideas below the patch.
>
> ---
> Makefile | 1 +
> git-put.sh | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 71 insertions(+), 0 deletions(-)
> create mode 100644 git-put.sh
>
> diff --git a/Makefile b/Makefile
> index e40ac0c..4564506 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -368,6 +368,7 @@ SCRIPT_SH += git-merge-one-file.sh
> SCRIPT_SH += git-merge-resolve.sh
> SCRIPT_SH += git-mergetool.sh
> SCRIPT_SH += git-pull.sh
> +SCRIPT_SH += git-put.sh
> SCRIPT_SH += git-quiltimport.sh
> SCRIPT_SH += git-rebase.sh
> SCRIPT_SH += git-repack.sh
> diff --git a/git-put.sh b/git-put.sh
> new file mode 100644
> index 0000000..f673e14
> --- /dev/null
> +++ b/git-put.sh
> @@ -0,0 +1,70 @@
> +#!/bin/sh
> +
> +SUBDIRECTORY_OK=Yes
> +OPTIONS_KEEPDASHASH=Yes
> +OPTIONS_SPEC="\
> +git put [options] <from> <to> [--] <file...>
> +
> +Move contents from one place to another, where <from> and <to> are one of:
> + 1. A commit (e.g., master, HEAD~10, v1.7.5)
> + 2. The special token INDEX to indicate git's index.
> + 3. The special token WORKTREE to indicate the working directory.
> +
> +Options:
> +--
> +p don't move whole files; use the patch interface
> +"
> +. git-sh-setup
> +
> +patch=
> +while test $# != 0; do
> + case "$1" in
> + -p) patch=--patch ;;
> + --) shift; break ;;
> + *) usage ;;
> + esac
> + shift
> +done
> +test $# -lt 2 && usage
> +
> +from=$1; shift
> +to=$1; shift
> +test "$1" = "--" && shift
> +
> +type_of() {
> + case "$1" in
> + INDEX) echo index ;;
> + WORKTREE) echo worktree ;;
> + *) echo commit ;;
> + esac
> +}
> +
> +# Checkout contents to worktree without munging the index in
> +# between.
> +worktree_checkout() {
> + old=$GIT_INDEX_FILE
> + test -z "$old" && old=$(git rev-parse --git-dir)/index
> + new=$(git rev-parse --git-dir)/put-index.tmp
> + cp "$old" "$new" &&
> + GIT_INDEX_FILE=$new git checkout "$@"
> + status=$?
> + rm -f "$new"
> + exit $status
> +}
> +
> +case "$(type_of "$from"),$(type_of "$to")" in
> +*,commit)
> + die "You can't modify an existing commit." ;;
> +index,index)
> + die "You can't move content from the index on top of itself." ;;
> +worktree,index)
> + exec git add $patch -- "$@" ;;
> +commit,index)
> + exec git reset $patch "$from" -- "$@" ;;
> +index,worktree)
> + exec git checkout $patch -- "$@" ;;
> +worktree,worktree)
> + die "You can't move content in the worktree on top of itself." ;;
> +commit,worktree)
> + worktree_checkout $patch "$from" -- "$@" ;;
> +esac
>
>
> As you can see, this handles only three typoes of locations: the
> worktree, the index, and an arbitrary commit (really a tree-ish).
Last time we were stuck at the magic keywords INDEX and WORKTREE. What
if we sort of follow scp naming convention:
- Normal paths are working tree's paths
- Paths with a colon in it are in "remote" locations (index or a
tree). The part before colon specifies the location.
We could have:
git put <src> [<src>...] <dst>
git put <src> [<src>...] <dst> -- <pathspec>
Where <src> and <dst> could be
- <tree-ish> <colon> [<pathspec>]
- [0-3] <colon> [<pathspec>]
- <pathspec> (or plain path)
In the first form, pathspec could be specified in <src>. If <dst> is
worktree, then "." would be enough (or path to repo's root to be more
strict). In the second form, no pathspec can be part of <src> nor
<dst> because they're at the end already.
With this syntax we could have:
git put 0:path/to/file.c . (or git put 0: path/to/file.c)
-> copy file.c from index to worktree (at the same path "path/to/file.c")
git put path/to/file 0:
-> copy file to index
git put HEAD: . -- path/
-> checkout everything in path/ from HEAD
I'm not sure how mutiple <src> should work, but there may be a use case for it.
> Some other types I've thought of are:
> ...
> - branches as destinations; obviously we can't change an existing
> commit, but what about something like:
>
> git put WORKTREE BRANCH:foo
>
> to optionally create a new branch "refs/heads/foo" based on the
> current HEAD, push changes into a temporary index that matches its
> tip, and then making a new commit based on top.
>
> This would serve a similar purpose to stashes, except that they
> would be named and could operate as full branches. I would find it
> useful for picking apart a mass of worktree changes into discrete
> commits.
>
> - allow multiple destinations, like
>
> # equivalent to "git checkout --"
> git put HEAD INDEX,WORKTREE
These obviously do not work with the syntax I propose.
--
Duy
^ permalink raw reply
* Re: Including git-describe info as version strings for generic "-v" output
From: demerphq @ 2012-01-23 11:16 UTC (permalink / raw)
To: Harry portobello; +Cc: git
In-Reply-To: <CAG_NL2So7cf6o+en9ktHGr94Eu5WJ9giWq6OmSxK+ZL4RdtaGA@mail.gmail.com>
On 21 January 2012 20:09, Harry portobello <harryportobello@gmail.com> wrote:
> Hi all,
>
> I hope the subject makes sense -- I'll explain what I'm trying to do.
>
> I'm wondering what the best approaches are to being able to include
> output from git-describe [1] for generic version strings in projects
> managed by Git? This would have to work from within an
> autotools-managed project.
>
> At the moment, I've managed to hook the output from git-describe in to
> a few .m4 files, which works only at ./configure time -- but of
> course, with this being Git, I'd ideally like the same mechanism to
> work in a situation where someone does:
>
> $ git pull && make
>
> It's knowing how to plumb this in to the Makefile.am part I'm hazy over.
>
> Any help would be much appreciated.
FWIW Perl does something like this. Have a look at the Perl makefiles
for an example.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH] Fix typo in 1.7.9 release notes
From: mhagger @ 2012-01-23 12:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael Haggerty
From: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Documentation/RelNotes/1.7.9.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/RelNotes/1.7.9.txt b/Documentation/RelNotes/1.7.9.txt
index 9b0a6eb..f1294b4 100644
--- a/Documentation/RelNotes/1.7.9.txt
+++ b/Documentation/RelNotes/1.7.9.txt
@@ -63,7 +63,7 @@ Updates since v1.7.8
knows MATLAB.
* "git log --format='<format>'" learned new %g[nNeE] specifiers to
- show information from the reflog entries when warlking the reflog
+ show information from the reflog entries when walking the reflog
(i.e. with "-g").
* "git pull" can be used to fetch and merge an annotated/signed tag,
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH v2 2/3] git-p4: Search for parent commit on branch creation
From: Vitor Antunes @ 2012-01-23 13:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pete Wyckoff, Luke Diamand
In-Reply-To: <7v7h0ld58z.fsf@alter.siamese.dyndns.org>
Hi Junio,
On Sat, Jan 21, 2012 at 4:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Vitor Antunes <vitor.hda@gmail.com> writes:
>
>> A fast-import "checkpoint" call is required for each comparison because
>> diff-tree is only able to work with blobs on disk. But most of these
>> commits will not be part of the final imported tree, making fast-import
>> fail. To avoid this, the temporary branches are tracked and then removed
>> at the end of the import process.
>>
>> Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
>> ---
>
> It might make sense to squash 1/3 with this patch; the definition alone
> without any actual user would not be very useful and won't help hunting
> for breakages, if exists, in the future.
Makes sense. WIll correct as you suggest in v3.
>> @@ -2012,7 +2014,27 @@ class P4Sync(Command, P4UserMap):
>> parent = self.initialParents[branch]
>> del self.initialParents[branch]
>>
>> - self.commit(description, filesForCommit, branch, [branchPrefix], parent)
>> + parentFound = False
>> + if len(parent) > 0:
>> + tempBranch = os.path.join(self.tempBranchLocation, "%d" % (change))
>> + if self.verbose:
>> + print "Creating temporary branch: " + tempBranch
>> + self.commit(description, filesForCommit, tempBranch, [branchPrefix])
>> + self.tempBranches.append(tempBranch)
>> + self.checkpoint()
>> + for blob in read_pipe_lines("git rev-list --reverse --no-merges %s" % parent):
>> + blob = blob.strip()
>> + if len( read_pipe("git diff-tree %s %s" % (blob, tempBranch)) ) == 0:
>> + parentFound = True
>> + if self.verbose:
>> + print "Found parent of %s in commit %s" % (branch, blob)
>
> ... also this looks excessively deeply nested, which is a sign that it
> might be a good idea to refactor this part into a separate helper function
> or something.
I have to agree with you. Since v3 is required, I'll also include this
fix along.
Thanks,
Vitor
^ permalink raw reply
* Re: [RFC/PATCH] git put: an alternative to add/reset/checkout
From: Michael Nahas @ 2012-01-23 13:53 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jeff King, git, Scott Chacon, Jakub Narebski, Matthieu Moy,
Junio C Hamano
In-Reply-To: <CACsJy8BCGi3s8gXr4kk-u8tDWztV6ozg1Tap23Q=TxA5d9iL+g@mail.gmail.com>
On Mon, Jan 23, 2012 at 5:32 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>
> (Bringing up an old thread)
"...thank you so much for bringing up such a painful subject. While
you're at it, why don't you give me a nice paper cut and pour lemon
juice on it."
"git put" is "git cp". It copies from one filesystem (or a snapshot
of a filesystem) to another filesystem.
Without multiple working directories, a modifiable "stash", or a
(useful) name for the filesystem referred to as
"index"/"cache"/"staging area", there is only one filesystem that the
command can write to: the (singular) working directory.
So, "git put <src filesystem> -- <path>" is fine. It will copy from
the path in the src filesystem to the path in the current working
directory. I don't think the command "put" is a great name for that.
Since we already have some strange double-usage commands like "git
checkout --" and "git reset --", perhaps this should be "git
cherry-pick --".
<rant>
But for my money, "git cp" is clearer and I'd love to get rid of the
user-confusing double-usage commands. I'd replace "git checkout --"
with "git cp NEXT WTREE -- <path>" and replace "git reset --" with
"git cp HEAD NEXT --" where NEXT is the filesystem represented by the
"index"/"cache"/"staging area" and WTREE is an alias for the working
directory.
</rant>
Still, good luck. It's a useful addition even if it is "git cherry-pick --".
Mike
>
>
> On Wed, Jun 8, 2011 at 3:06 AM, Jeff King <peff@peff.net> wrote:
> > ...
> > But another way to think about it is that commits, the index, and the
> > working tree are all "locations" with content. And one common operation
> > you may want to do is to move content from one spot to another, either
> > whole, by file, or by diff hunks. To a new user, knowing that "add" is
> > the command for moving content from thet working tree to the index does
> > not help them know which command to use to do the opposite content
> > movement.
> > ...
> > My idea is therefore to have a single command for moving content from
> > one location to another. You specify a source and a destination and get
> > a uniform interface for moving content.
> >
> > A proof-of-concept patch is below. Be aware that is meant to be
> > illustrative and is not well tested. Also, it is a minimal presentation
> > of the concept. Other "locations" may also be meaningful. I'll include
> > some ideas below the patch.
> >
> > ---
> > Makefile | 1 +
> > git-put.sh | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 71 insertions(+), 0 deletions(-)
> > create mode 100644 git-put.sh
> >
> > diff --git a/Makefile b/Makefile
> > index e40ac0c..4564506 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -368,6 +368,7 @@ SCRIPT_SH += git-merge-one-file.sh
> > SCRIPT_SH += git-merge-resolve.sh
> > SCRIPT_SH += git-mergetool.sh
> > SCRIPT_SH += git-pull.sh
> > +SCRIPT_SH += git-put.sh
> > SCRIPT_SH += git-quiltimport.sh
> > SCRIPT_SH += git-rebase.sh
> > SCRIPT_SH += git-repack.sh
> > diff --git a/git-put.sh b/git-put.sh
> > new file mode 100644
> > index 0000000..f673e14
> > --- /dev/null
> > +++ b/git-put.sh
> > @@ -0,0 +1,70 @@
> > +#!/bin/sh
> > +
> > +SUBDIRECTORY_OK=Yes
> > +OPTIONS_KEEPDASHASH=Yes
> > +OPTIONS_SPEC="\
> > +git put [options] <from> <to> [--] <file...>
> > +
> > +Move contents from one place to another, where <from> and <to> are one of:
> > + 1. A commit (e.g., master, HEAD~10, v1.7.5)
> > + 2. The special token INDEX to indicate git's index.
> > + 3. The special token WORKTREE to indicate the working directory.
> > +
> > +Options:
> > +--
> > +p don't move whole files; use the patch interface
> > +"
> > +. git-sh-setup
> > +
> > +patch=
> > +while test $# != 0; do
> > + case "$1" in
> > + -p) patch=--patch ;;
> > + --) shift; break ;;
> > + *) usage ;;
> > + esac
> > + shift
> > +done
> > +test $# -lt 2 && usage
> > +
> > +from=$1; shift
> > +to=$1; shift
> > +test "$1" = "--" && shift
> > +
> > +type_of() {
> > + case "$1" in
> > + INDEX) echo index ;;
> > + WORKTREE) echo worktree ;;
> > + *) echo commit ;;
> > + esac
> > +}
> > +
> > +# Checkout contents to worktree without munging the index in
> > +# between.
> > +worktree_checkout() {
> > + old=$GIT_INDEX_FILE
> > + test -z "$old" && old=$(git rev-parse --git-dir)/index
> > + new=$(git rev-parse --git-dir)/put-index.tmp
> > + cp "$old" "$new" &&
> > + GIT_INDEX_FILE=$new git checkout "$@"
> > + status=$?
> > + rm -f "$new"
> > + exit $status
> > +}
> > +
> > +case "$(type_of "$from"),$(type_of "$to")" in
> > +*,commit)
> > + die "You can't modify an existing commit." ;;
> > +index,index)
> > + die "You can't move content from the index on top of itself." ;;
> > +worktree,index)
> > + exec git add $patch -- "$@" ;;
> > +commit,index)
> > + exec git reset $patch "$from" -- "$@" ;;
> > +index,worktree)
> > + exec git checkout $patch -- "$@" ;;
> > +worktree,worktree)
> > + die "You can't move content in the worktree on top of itself." ;;
> > +commit,worktree)
> > + worktree_checkout $patch "$from" -- "$@" ;;
> > +esac
> >
> >
> > As you can see, this handles only three typoes of locations: the
> > worktree, the index, and an arbitrary commit (really a tree-ish).
>
> Last time we were stuck at the magic keywords INDEX and WORKTREE. What
> if we sort of follow scp naming convention:
>
> - Normal paths are working tree's paths
> - Paths with a colon in it are in "remote" locations (index or a
> tree). The part before colon specifies the location.
>
> We could have:
>
> git put <src> [<src>...] <dst>
> git put <src> [<src>...] <dst> -- <pathspec>
>
> Where <src> and <dst> could be
>
> - <tree-ish> <colon> [<pathspec>]
> - [0-3] <colon> [<pathspec>]
> - <pathspec> (or plain path)
>
> In the first form, pathspec could be specified in <src>. If <dst> is
> worktree, then "." would be enough (or path to repo's root to be more
> strict). In the second form, no pathspec can be part of <src> nor
> <dst> because they're at the end already.
>
> With this syntax we could have:
>
> git put 0:path/to/file.c . (or git put 0: path/to/file.c)
> -> copy file.c from index to worktree (at the same path "path/to/file.c")
> git put path/to/file 0:
> -> copy file to index
> git put HEAD: . -- path/
> -> checkout everything in path/ from HEAD
>
> I'm not sure how mutiple <src> should work, but there may be a use case for it.
>
> > Some other types I've thought of are:
> > ...
> > - branches as destinations; obviously we can't change an existing
> > commit, but what about something like:
> >
> > git put WORKTREE BRANCH:foo
> >
> > to optionally create a new branch "refs/heads/foo" based on the
> > current HEAD, push changes into a temporary index that matches its
> > tip, and then making a new commit based on top.
> >
> > This would serve a similar purpose to stashes, except that they
> > would be named and could operate as full branches. I would find it
> > useful for picking apart a mass of worktree changes into discrete
> > commits.
> >
> > - allow multiple destinations, like
> >
> > # equivalent to "git checkout --"
> > git put HEAD INDEX,WORKTREE
>
> These obviously do not work with the syntax I propose.
> --
> Duy
^ 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