* Re: git stash path/to/only/one/subdirectory
From: Johan Herland @ 2010-12-08 15:38 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <AANLkTim+sOeVfkAac1v-CsD5GG8Vj2VSjXn-9SSw+Hjb@mail.gmail.com>
On Wednesday 08 December 2010, Patrick Doyle wrote:
> Looking at the man page for git-stash, it seems like I can do this
> with the --patch option to git-stash, but I figured I'd ask the
> questions anyway...
>
> Is it possible to git-stash a single directory, while leaving the
> rest of my working copy in the state it's in?
>
> In my particular case (as of 9:00am this morning), I've realized that
> I want to split my work into 2 separate commits; I'm not done with
> either of them yet; and they are in completely separate directories
> from each other. I would like to do something like:
>
> $ git stash --subdir-only dir1
> edit/test stuff in dir2, possibly committing once or twice along the
> way $ git commit dir2
> go off and do other stuff for a while, and come back to the dir1
> stuff I was playing with
> $ git stash pop
> finish the dir1 work
> $ git commit dir1
Usually, I solve these problems by staging dir2 with 'git add dir2' and
then committing it ('git commit' without -a), then running 'git stash'
to remove dir1 changes from the worktree. I can now test the dir2
changes and fix the dir2 commit (if needed) with 'git commit --amend'.
Then, when it looks good, I can bring dir1 back with 'git stash pop'
and continue working on that.
You should also look at 'git add -p' to stage changes hunk-by-hunk. That
is really helpful when dir1 changes and dir2 changes are not in
separate directories.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git-svn checksum mismatch
From: Reynald Borer @ 2010-12-08 16:13 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTinZocHeu3ho6U9oL=Q608NBJaUf-nKehppWaDYp@mail.gmail.com>
Hello Patrick,
Thanks for your quick answer. I'm doing a checkout on a Linux box, so
there is no problem with the case of files. Thanks for the tip anyway.
Apparently it seems that SVN commits causing issues are the ones where
the svn property "eol-style" has been changed to native (because the
repositories are shared between Windows and Linux clients). I tried to
reproduce this in a clean repository but I did not succeed at
exhibiting the problem.
Cheers,
Reynald
On Wed, Dec 8, 2010 at 4:36 PM, Patrick Doyle <wpdster@gmail.com> wrote:
> On Wed, Dec 8, 2010 at 10:17 AM, Reynald Borer <reynald.borer@gmail.com> wrote:
>> Hi again,
>>
>> Sorry to bother you again but I am still experiencing this problem. I
>> tried with a more up to date version of Git (version 1.7.3.2), and
>> this is still happening. I also tried to diagnose this issue but I am
>> completely lost.
>>
>> I am very annoyed because this is preventing me using Git on all my
>> SVN repos (2 are failing on 30...)
>>
>> Does anyone know how I could try to solve this issue?
>
> Tossing out a random theory with nothing to back it up...
>
> I don't know anything about the "well known checksum mismatch
> problem", but are you trying to check out the SVN repository onto a
> file system that is case insensitive, such as on a Windows or (default
> setup) Mac host?
>
> If so, the repository might have files with different spellings such
> as README and Readme in the same directory, which will get clobbered
> on such a host. I've run into that issue in the past in a different
> context.
>
> --wpd
>
^ permalink raw reply
* Re: [PATCH] t9143: do not fail when unhandled.log.gz is not created
From: Torsten Bögershausen @ 2010-12-08 16:25 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Torsten Bögershausen
In-Reply-To: <20101206192326.GA12383@dcvr.yhbt.net>
On 12/06/2010 08:23 PM, Eric Wong wrote:
> Torsten Bögershausen<tboegi@web.de> wrote:
>> Commit df73af5f66 is does not let the test case fail,
>> when Compress::Zlib is missing.
>> But:
>> On a MacOS X 10.6 system with missing Compress::Zlib
>> using svn version 1.6.5 (r38866) the gz file is created.
>> Solution:
>> Check for the existance of the unhandled.log.gz file.
>
> I wonder if your system could have multiple perl installations and
> git-svn is calling one while the shell scripts are calling another.
> I'm not sure if there is another way the gz file could be created while
> Compress::Zlib is missing.
>
>> Signed-off-by: Torsten Bögershausen<tboegi@web.de>
>
> Torsten Bögershausen wrote in<4CFA27DD.7030105@web.de>:
>> Now we do not depend on internal implementation details of svn.
>> And the code is 3% easier to understand :-)
>
> I agree on this point completely
>
> Acked-by: Eric Wong<normalperson@yhbt.net>
>
>> ---
>> t/t9143-git-svn-gc.sh | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/t/t9143-git-svn-gc.sh b/t/t9143-git-svn-gc.sh
>> index 337ea59..8a95d78 100755
>> --- a/t/t9143-git-svn-gc.sh
>> +++ b/t/t9143-git-svn-gc.sh
>> @@ -37,7 +37,7 @@ test_expect_success 'git svn gc runs' 'git svn gc'
>> test_expect_success 'git svn index removed' '! test -f
>> .git/svn/refs/remotes/git-svn/index'
>> -if perl -MCompress::Zlib -e 0 2>/dev/null
>> +if test -r .git/svn/refs/remotes/git-svn/unhandled.log.gz
>> then
>> test_expect_success 'git svn gc produces a valid gzip file' '
>> gunzip .git/svn/refs/remotes/git-svn/unhandled.log.gz
>> --
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Eric,
thanks for the input.
I have indeed 2 perl versions:
find / -xdev -name perl -type f 2>/dev/null | xargs ls -l
-rwxr-xr-x 2 root admin 1297824 Jan 7 2010 /opt/local/bin/perl
-rwxr-xr-x 2 root admin 1297824 Jan 7 2010
/opt/local/var/macports/software/perl5.8/5.8.9_3/opt/local/bin/perl
-rwxr-xr-x 1 root wheel 86000 Jun 26 2009 /usr/bin/perl
-r--r--r-- 1 root wheel 1813 May 18 2009 /usr/share/file/magic/perl
which perl
/opt/local/bin/perl
/opt/local/bin/perl -MCompress::Zlib -e 0 ; echo $?
Can't locate Compress/Zlib.pm in @INC (@INC contains: /sw/lib/perl5
/sw/lib/perl5/darwin /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level
/opt/local/lib/perl5/site_perl/5.8.9 /opt/local/lib/perl5/site_perl
/opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level
/opt/local/lib/perl5/vendor_perl/5.8.9 /opt/local/lib/perl5/vendor_perl
/opt/local/lib/perl5/5.8.9/darwin-2level /opt/local/lib/perl5/5.8.9 .).
BEGIN failed--compilation aborted.
2
/usr/bin/perl -MCompress::Zlib -e 0 ; echo $?
0
==================
If you agree, I will send a V2 version of the patch, which
will use the following:
---------------------------
if test -r .git/svn/refs/remotes/git-svn/unhandled.log.gz
then
test_expect_success 'git svn gc produces a valid gzip file' '
gunzip .git/svn/refs/remotes/git-svn/unhandled.log.gz
'
fi
----------------
This will simply check if the unhandled.log.gz exist,
and if, it will be unpacked.
I removed the else and
say "# Perl Compress::Zlib unavailable, skipping gunzip test"
/Torsten
^ permalink raw reply
* cherry-pick / pre-commit hook?
From: Dave Abrahams @ 2010-12-08 17:10 UTC (permalink / raw)
To: git
Is there a good reason that git cherry-pick (without --no-commit)
doesn't run my pre-commit hook? Is there a hook that cherry-pick
/will/ run instead?
Thanks!
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* StandardInput Not Continuing Process
From: Chase Brammer @ 2010-12-08 17:25 UTC (permalink / raw)
To: git
I am try to directly interact with Git by using only stdin, stdout,
and stderr. So
not going through a terminal at all, but calling Git directly. I am
having an issue
with being able to continue a process that requires input.
For example, doing a clone from a HTTPS server may require a username/password.
I writing the password as utf, and also tried just UTF byes (ie no
prepended 16-bit int)
but am unable to get the process to continue and start the clone process.
Is there some signal, or trick to getting the process to continue? I
thought that sending a
"\n" would work, but that doesn't seem to be working either.
Thanks for any help!
Chase
^ permalink raw reply
* Push to all repositories
From: Kevin Sheedy @ 2010-12-08 17:39 UTC (permalink / raw)
To: git
Will git let me push my changes to every member of the team?
I find a big problem with CVS & SVN is that I have to explicitly update my
code in order to keep in sync. This is a real pain-point as I often have to
do it several times a day and it can be very slow. We still regularly get
problems caused by developers being out of sync. Most people become
reluctant to do an update at all as they fear it will cause errors.
Clearcase has a great solution to this, "dynamic views". Whenever I check in
some code, the whole team magically get's my changes straight away.
Normally, they don't even notice, they're just forced to stay in sync. This
drastically reduces the number of 'code conflicts' where people make changes
to 'stale' files. This enforces the practise of "catching errors early". It
also keeps developers "honest" as they have to keep the quality of their
checkins high lest they get shouted at by the rest of the team.
Will git let a team stay in sync without everyone having to do manual
updates?
Basically, I want every developer to be able to push their code to the whole
team.
--
View this message in context: http://git.661346.n2.nabble.com/Push-to-all-repositories-tp5816069p5816069.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: cherry-pick / pre-commit hook?
From: Jonathan Nieder @ 2010-12-08 17:53 UTC (permalink / raw)
To: Dave Abrahams; +Cc: git
In-Reply-To: <m2wrnktcl2.wl%dave@boostpro.com>
Dave Abrahams wrote:
> Is there a good reason that git cherry-pick (without --no-commit)
> doesn't run my pre-commit hook?
Interesting question.
$ git grep -F -e '"cherry-pick"'
[...]
git.c: { "cherry-pick", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },
$ git grep -F -e cmd_cherry_pick
builtin.h:extern int cmd_cherry_pick(int argc, const char **argv, const char *prefix);
builtin/revert.c:int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
git.c: { "cherry-pick", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },
cherry-pick is implemented in builtin/revert.c. How does it invoke
the "git commit" machinery? Explicitly, as luck would have it.
$ git grep --show-function -F -h -C5 -e '"commit"' -- builtin/revert.c
static int run_git_commit(const char *defmsg)
{
/* 6 is max possible length of our args array including NULL */
const char *args[6];
int i = 0;
args[i++] = "commit";
args[i++] = "-n";
if (signoff)
args[i++] = "-s";
[...]
So cherry-pick deliberately uses -n (= --no-verify) when it calls "git commit".
Why, though?
$ git log --oneline --follow -S'"-n"' -- builtin/revert.c
cfd9c27 Allow cherry-pick (and revert) to add signoff line
f810379 Make builtin-revert.c use parse_options.
9509af6 Make git-revert & git-cherry-pick a builtin
The '-n' was copied from the old git-revert.sh script when cherry-pick
was made builtin. Not to let the trail grow cold:
$ git log --oneline --follow -S-n -- git-revert.sh
9509af6 Make git-revert & git-cherry-pick a builtin
abd6970 cherry-pick: make -r the default
674b280 Add documentation for git-revert and git-cherry-pick.
8bf14d6 Document the --(no-)edit switch of git-revert and git-cherry-pick
b788498 git-revert: make --edit default.
e2f5f6e Do not require clean tree when reverting and cherry-picking.
9fa4db5 Do not verify reverted/cherry-picked/rebased patches.
[...]
$ git show -s 9fa4db5
commit 9fa4db544e2e4d6c931f6adabc5270daec041536
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Aug 29 21:19:04 2005 -0700
Do not verify reverted/cherry-picked/rebased patches.
The original committer may have used validation criteria that is less
stricter than yours. You do not want to lose the changes even if they
are done in substandard way from your 'commit -v' verifier's point of
view.
Signed-off-by: Junio C Hamano <junkio@cox.net>
$
At last, an answer. The main purpose of the pre-commit hook (and
builtin checks that preceded it) is to avoid introducing regressions
in whitespace style, encoding, and so forth; but it would make
cherry-picking unnecessarily difficult, without preventing
regressions, to apply the same standards to existing code.
> Is there a hook that cherry-pick
> /will/ run instead?
"git log --grep=pre-commit" seems to suggest that the commit-msg and
post-commit hooks will be run. But first, what are you trying to
accomplish? Maybe there is a simpler way, or maybe with that use
case in mind we can make changes to support it better.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: Push to all repositories
From: Jonathan Nieder @ 2010-12-08 18:00 UTC (permalink / raw)
To: Kevin Sheedy; +Cc: git
In-Reply-To: <1291829983410-5816069.post@n2.nabble.com>
Kevin Sheedy wrote:
> Basically, I want every developer to be able to push their code to the whole
> team.
What does this mean, in practice? Do you want (1) the code in their
working directories to change under their feet, (2) the code you've
written to be immediately available to them in case they pull out the
network cable, or something else?
If case (2), then git currently provides support for fetching from
multiple repositories at once:
$ git fetch --multiple alice bob sam
but does not include such support for pushing. One can do so explicitly
like so:
$ for repo in alice blob sam
do
git push $repo *:refs/remotes/kevin/*
done
Regards,
Jonathan
^ permalink raw reply
* Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators
From: Jonathan Nieder @ 2010-12-08 18:06 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Kevin Ballard, Yann Dirson, Jeff King,
Jakub Narebski
In-Reply-To: <1291820319-12455-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
> Let's start off from where the previous discussion [1] stopped. People
> seem to agree ref^{/regex} is a good choice. But we have not come to
> conclusion how to specify the count yet. Possible suggestions are
>
> - ref^{/foo}2
> - ref^{2/foo}
> - ref^{:2/foo}
> - ref^{2nd/foo}
How about
ref^{/foo}^^{/foo}
?
^ permalink raw reply
* Re: cmd_cherry in builtin/log.c?
From: Jonathan Nieder @ 2010-12-08 18:09 UTC (permalink / raw)
To: Thiago Farina; +Cc: Git Mailing List, rene.scharfe
In-Reply-To: <AANLkTik7+WAk0mx0G7b565eCihB5SGNBDuYLdfPzq7pr@mail.gmail.com>
Thiago Farina wrote:
> Yup, thanks for digging into it. Now makes sense.
Mm, I was hoping for "thanks for teaching me to dig into it". :)
^ permalink raw reply
* [PATCH v2.1 3/4] describe: Store commit_names in a hash table by commit SHA1
From: Anders Kaseorg @ 2010-12-08 18:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, git, SZEDER Gábor, Kirill Smelkov,
Thomas Rast
In-Reply-To: <alpine.DEB.2.02.1012072343300.23348@dr-wily.mit.edu>
describe is currently forced to look up the commit at each tag in
order to store the struct commit_name pointers in struct commit.util.
For --exact-match queries, those lookups are wasteful. In preparation
for removing them, put the commit_names into a hash table, indexed by
commit SHA1, that can be used to quickly check for exact matches.
Signed-off-by: Anders Kaseorg <andersk@ksplice.com>
---
Change from v2: I had forgotten to make ‘names’ static again (thanks
Jonathan).
builtin/describe.c | 36 +++++++++++++++++++++++++++++++-----
1 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index 5b8461d..5d709b6 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -6,6 +6,7 @@
#include "exec_cmd.h"
#include "parse-options.h"
#include "diff.h"
+#include "hash.h"
#define SEEN (1u<<0)
#define MAX_TAGS (FLAG_BITS - 1)
@@ -22,7 +23,7 @@ static int tags; /* Allow lightweight tags */
static int longformat;
static int abbrev = DEFAULT_ABBREV;
static int max_candidates = 10;
-static int found_names;
+static struct hash_table names;
static const char *pattern;
static int always;
static const char *dirty;
@@ -34,6 +35,8 @@ static const char *diff_index_args[] = {
struct commit_name {
+ struct commit_name *next;
+ unsigned char peeled[20];
struct tag *tag;
unsigned prio:2; /* annotated tag = 2, tag = 1, head = 0 */
unsigned name_checked:1;
@@ -44,6 +47,19 @@ static const char *prio_names[] = {
"head", "lightweight", "annotated",
};
+static inline unsigned int hash_sha1(const unsigned char *sha1)
+{
+ return *(unsigned int *)sha1;
+}
+
+static inline struct commit_name *find_commit_name(const unsigned char *peeled)
+{
+ struct commit_name *n = lookup_hash(hash_sha1(peeled), &names);
+ while (n && !!hashcmp(peeled, n->peeled))
+ n = n->next;
+ return n;
+}
+
static int replace_name(struct commit_name *e,
int prio,
const unsigned char *sha1,
@@ -82,12 +98,22 @@ static void add_to_known_names(const char *path,
int prio,
const unsigned char *sha1)
{
- struct commit_name *e = commit->util;
+ const unsigned char *peeled = commit->object.sha1;
+ struct commit_name *e = find_commit_name(peeled);
struct tag *tag = NULL;
if (replace_name(e, prio, sha1, &tag)) {
if (!e) {
+ void **pos;
e = xmalloc(sizeof(struct commit_name));
commit->util = e;
+ hashcpy(e->peeled, peeled);
+ pos = insert_hash(hash_sha1(peeled), e, &names);
+ if (pos) {
+ e->next = *pos;
+ *pos = e;
+ } else {
+ e->next = NULL;
+ }
}
e->tag = tag;
e->prio = prio;
@@ -95,7 +121,6 @@ static void add_to_known_names(const char *path,
hashcpy(e->sha1, sha1);
e->path = path;
}
- found_names = 1;
}
static int get_name(const char *path, const unsigned char *sha1, int flag, void *cb_data)
@@ -240,7 +265,7 @@ static void describe(const char *arg, int last_one)
if (!cmit)
die("%s is not a valid '%s' object", arg, commit_type);
- n = cmit->util;
+ n = find_commit_name(cmit->object.sha1);
if (n && (tags || all || n->prio == 2)) {
/*
* Exact match to an existing ref.
@@ -418,8 +443,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
return cmd_name_rev(i + argc, args, prefix);
}
+ init_hash(&names);
for_each_rawref(get_name, NULL);
- if (!found_names && !always)
+ if (!names.nr && !always)
die("No names found, cannot describe anything.");
if (argc == 0) {
--
1.7.3.3
^ permalink raw reply related
* Re: Status of the svn remote helper project (Dec 2010, #1)
From: Tomas Carnecky @ 2010-12-08 18:26 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Ramkumar Ramachandra, Sverre Rabbelier, David Barr,
Sam Vilain, Stephen Bash
In-Reply-To: <20101205113717.GH4332@burratino>
On 12/5/10 12:37 PM, Jonathan Nieder wrote:
> --------------------------------------------------
> [Out of tree, stalled]
>
> * tc/remote-helper-usability: $gmane/157860
> . Register new packs after the remote helper is done fetching
> . Properly record history of the notes ref
> . Fix ls-remote output when displaying impure refs
> . Add git-remote-svn
> . Introduce the git fast-import-helper
> . Rename get_mode() to decode_tree_mode() and export it
> . Allow the transport fetch command to add additional refs
> . Allow more than one keepfile in the transport
> . Remote helper: accept ':<value> <name>' as a response to 'list'
>
> The fourth-from-top seems a bit hard to review. If it really is
> necessary to introduce a separate program with a separate interface,
> maybe a compile-time flag to choose between them would help?
I simplified the code and the requirements on fast-import are much
lighter now. All I need is a way to tell fast-import to stop writing
refs and after each commit write its sha1 to stdout. It's possible to
modify fast-import.c with a small patch to make it behave like that.
However, I haven't followed the svn remote helper that much lately so I
don't know whether one of the other patches already modifies fast-import
in this way.
From the beginning my code was meant to be just an example how the
interaction between git and the svn remote helper could look like. For
example I save the svn rev <-> sha1 mapping in notes, which is appears
to work well. I'll take a look if I'll be able to use the svn-fe in my
script.
tom
^ permalink raw reply
* Re: [PATCH 01/14] msvc: Fix compilation errors in compat/win32/sys/poll.c
From: Johannes Sixt @ 2010-12-08 19:42 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, kusmabite, GIT Mailing-list
In-Reply-To: <4CFECEBB.7060703@ramsay1.demon.co.uk>
On Mittwoch, 8. Dezember 2010, Ramsay Jones wrote:
> Johannes Sixt wrote:
> > On Samstag, 4. Dezember 2010, Ramsay Jones wrote:
> >> diff --git a/compat/win32/sys/poll.c b/compat/win32/sys/poll.c
> >> index 7e74ebe..708a6c9 100644
> >> --- a/compat/win32/sys/poll.c
> >> +++ b/compat/win32/sys/poll.c
> >> @@ -34,6 +34,9 @@
> >>
> >> #if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
> >> # define WIN32_NATIVE
> >> +# if defined (_MSC_VER)
> >> +# define _WIN32_WINNT 0x0502
> >> +# endif
> >> # include <winsock2.h>
> >> # include <windows.h>
> >> # include <io.h>
> >
> > Don't you have to do the same in git-compat-util.h?
>
> No. compat/win32/sys/poll.c doesn't include git-compat-util.h (and I
> don't think it should),
I know and I agree.
> so adding it there would not solve the immediate
> problem.
Didn't I say: "do the same..."? :-) So the question remains open. After all,
by doing so, you would make sure that the rest of git sees the same API
(struct definitions and #defined constants) as compat/win32/sys/poll.c, no?
-- Hannes
^ permalink raw reply
* Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators
From: Jakub Narebski @ 2010-12-08 19:47 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Kevin Ballard, Yann Dirson, Jeff King
In-Reply-To: <1291820319-12455-1-git-send-email-pclouds@gmail.com>
On Wed, 8 Dec 2010, Nguyễn Thái Ngọc Duy wrote:
> Let's start off from where the previous discussion [1] stopped. People
> seem to agree ref^{/regex} is a good choice. But we have not come to
> conclusion how to specify the count yet. Possible suggestions are
>
> - ref^{/foo}2
> - ref^{2/foo}
> - ref^{:2/foo}
> - ref^{2nd/foo}
>
> For whatever syntax chosen, :/ should benefit too. I notice that :/!
> is reserved for future use. Perhaps :/!2/regex is not too cryptic?
I wonder if it would be possible to make :/<regex> (which looks a bit
like searching the index) to be an alias to --all^{/<regex>}...
Or if we can make ^{/<regex>} to act on revision range specified by
earlier commits, so for example foo..bar^{/<regex>} would work.
> I'd also like to do case-insensitive regex, by the way. :/!2i/regex
> looks a bit ugly.
The '2nd' idea came from Perl 6 regexp / grammars, see for example
https://github.com/perlpilot/perl6-docs/blob/master/intro/p6-regex-intro.pod
There are two other modifiers for matching a pattern some number of times
or only matching, say, the third time we see a pattern in a string. These
modifiers are a little strange in that their short-hand forms consist of
a number followed by some text:
modifier short-hand meaning
:x() :1x,:4x,:12x match some number of times
:nth() :1st,:2nd,:3rd,:4th match only the Nth occurance
Here are some examples to illustrate these modifiers:
$_ = "foo bar baz blat";
m :3x/ a / # matches the "a" characters in each word
m :nth(3)/ \w+ / # matches "baz"
So it could be e.g. 'foo^{:2nd/<regexp>}' (note that there is no trailing
/ closing regexp, i.e. it is not 'foo^{:2nd/<regexp>/}').
So if we chose this, why don't we follow Perl 6 rule of combining modifiers
http://perlcabal.org/syn/S05.html#Modifiers, so it would be
foo^{:2nd:i/<regexp>}
or
foo^{:i:nth(2)/<regexp>}
As to :/!<regexp> form: isn't it reserved for non-match? If not, then
perhaps
:/!2nd:i/<regexp>
> [1] http://mid.gmane.org/9D675671-693D-4B59-AF2A-0EFE4C537362@sb.org
>
> Nguyễn Thái Ngọc Duy (2):
> get_sha1_oneline: allow to input commit_list
> get_sha1: support ref^{/regex} syntax
>
> Documentation/revisions.txt | 7 ++++++
> sha1_name.c | 45 ++++++++++++++++++++++++++++++++----------
> 2 files changed, 41 insertions(+), 11 deletions(-)
Thank you for working on this.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators
From: Jakub Narebski @ 2010-12-08 19:51 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Nguyễn Thái Ngọc Duy, git, Junio C Hamano,
Kevin Ballard, Yann Dirson, Jeff King
In-Reply-To: <20101208180605.GD5687@burratino>
Dnia środa 8. grudnia 2010 19:06, Jonathan Nieder napisał:
> Nguyễn Thái Ngọc Duy wrote:
>
> > Let's start off from where the previous discussion [1] stopped. People
> > seem to agree ref^{/regex} is a good choice. But we have not come to
> > conclusion how to specify the count yet. Possible suggestions are
> >
> > - ref^{/foo}2
> > - ref^{2/foo}
> > - ref^{:2/foo}
> > - ref^{2nd/foo}
>
> How about
>
> ref^{/foo}^^{/foo}
>
> ?
I'll assume that there is invisible ";)" emoticon here.
First, it would be ref^{/foo}^@^{/foo}, otherwise you would follow only
first parent.
Second, consider ref^{:nth(10)/foo} in your workaround...
;-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 04/14] msvc: Fix macro redefinition warnings
From: Johannes Sixt @ 2010-12-08 19:51 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: Ramsay Jones, Junio C Hamano, GIT Mailing-list, patthoyts,
pharris
In-Reply-To: <AANLkTimpj31CSzaxH4ZuYdADvtV4KSwfk04eGSRYSLFH@mail.gmail.com>
On Mittwoch, 8. Dezember 2010, Sebastian Schuberth wrote:
> Indeed, I remember that back then my
> msysgit working tree did not compile with MSVC if I didn't have these
> defines (and I vaguely remember that this was caused by MSVC using
> different a header file than MinGW, or in a different order, or
> something similar).
...
> After defining LF_FACESIZE and TMPF_TRUETYPE in winansi.c, and
> INTMAX_MAX in git-compat-util.h, I was also able to compile the
> v1.7.3.2.msysgit.0 tag with MSVC. If I revert 4091bfc on top of it, it
> still compiles fine for me.
>
> > So, once again, I see no reason to keep them ... Unless you know
> > otherwise.
>
> I agree to remove the lines and vote in favor of Ramsay's patch. Feel
> free to add me as Signed-off-by or Acked-by.
Under these circumstances, I agree as well with Ramsay's patch.
-- Hannes
^ permalink raw reply
* missing tags!
From: layer @ 2010-12-08 19:44 UTC (permalink / raw)
To: git
I have a repo to which I push to frequently. For each release of the
software from this repo, I create an annotated tag and push it to this
repo. I noticed yesterday that he has a single tag in it, when it
should have 100+. The tag there was the last one I pushed to it.
The missing tags were created with
git tag -a -m "release 4.2rm t1" release42rm_t1 HEAD
and pushed to the (bare) repo in question with
git push origin release42rm_t1
I cannot imagine how the tags got deleted, and I'm looking for some
guidance.
Thanks.
Kevin
^ permalink raw reply
* Re: missing tags!
From: Jeff King @ 2010-12-08 20:18 UTC (permalink / raw)
To: layer; +Cc: git
In-Reply-To: <7986.1291837475@relay.known.net>
On Wed, Dec 08, 2010 at 11:44:35AM -0800, layer wrote:
> I have a repo to which I push to frequently. For each release of the
> software from this repo, I create an annotated tag and push it to this
> repo. I noticed yesterday that he has a single tag in it, when it
> should have 100+. The tag there was the last one I pushed to it.
>
> The missing tags were created with
>
> git tag -a -m "release 4.2rm t1" release42rm_t1 HEAD
>
> and pushed to the (bare) repo in question with
>
> git push origin release42rm_t1
>
> I cannot imagine how the tags got deleted, and I'm looking for some
> guidance.
How did you verify that the tags were deleted? Are you sure they are not
just packed?
-Peff
^ permalink raw reply
* Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators
From: Jonathan Nieder @ 2010-12-08 20:40 UTC (permalink / raw)
To: Jakub Narebski
Cc: Nguyễn Thái Ngọc Duy, git, Junio C Hamano,
Kevin Ballard, Yann Dirson, Jeff King
In-Reply-To: <201012082047.44022.jnareb@gmail.com>
Jakub Narebski wrote:
> So if we chose this, why don't we follow Perl 6 rule of combining modifiers
> http://perlcabal.org/syn/S05.html#Modifiers, so it would be
>
> foo^{:2nd:i/<regexp>}
>
> or
>
> foo^{:i:nth(2)/<regexp>}
Very nice.
^ permalink raw reply
* Re: cherry-pick / pre-commit hook?
From: Dave Abrahams @ 2010-12-08 21:22 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20101208175324.GB5687@burratino>
Hi Jonathan,
At Wed, 8 Dec 2010 11:53:24 -0600,
Jonathan Nieder wrote:
>
> $ git show -s 9fa4db5
> commit 9fa4db544e2e4d6c931f6adabc5270daec041536
> Author: Junio C Hamano <junkio@cox.net>
> Date: Mon Aug 29 21:19:04 2005 -0700
>
> Do not verify reverted/cherry-picked/rebased patches.
>
> The original committer may have used validation criteria that is less
> stricter than yours. You do not want to lose the changes even if they
> are done in substandard way from your 'commit -v' verifier's point of
> view.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> $
>
> At last, an answer. The main purpose of the pre-commit hook (and
> builtin checks that preceded it) is to avoid introducing regressions
> in whitespace style, encoding, and so forth; but it would make
> cherry-picking unnecessarily difficult, without preventing
> regressions, to apply the same standards to existing code.
I suspected as much.
>
> > Is there a hook that cherry-pick
> > /will/ run instead?
>
> "git log --grep=pre-commit" seems to suggest that the commit-msg and
> post-commit hooks will be run. But first, what are you trying to
> accomplish?
You're going to love this: I had sent a pull request upstream and the
maintainer of the project rejected my changes because I didn't follow
some formatting convention he didn't tell me about ;-). So I set up a
commit hook that would prevent me from making the same mistake again,
and cherry-picked the changes one-by-one. So it was exactly the same
scenario, except I am the author of the original changes.
I wonder whether this would have gone better had I used rebase.
> Maybe there is a simpler way, or maybe with that use
> case in mind we can make changes to support it better.
Looking forward to hearing more.
Thanks,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* how to have real (existing) submodules?
From: Oliver Kullmann @ 2010-12-08 20:58 UTC (permalink / raw)
To: git
Hi,
I have the following organisational problem:
Due to access restrictions, privacy, communication problems etc.
I need to have independent git repositories for various projects
(for example working on a scientific paper --- tossing the repos
as tarballs around is really great, and it works also for those
who do not want to use git). There repositories exist all at various
locations, often just local repositories, without internet access
(though some are on Github).
This creates obviously the problem of carrying them around (especially
given that certain places don't have Internet connection, and data
needs to be transferred via memory sticks).
I thought that "git submodule" would solve the problem, but now
I realised that these submodules are not "real", but they only contain
a bit of meta-data (this should really be said directly in the documentation).
So my hope, that I can have one super-repo, where I say, e.g., "git submodule foreach pull",
get the full super-repo, copy it on a memory stick, and then by pulling from
that copy I get everything into another super-repo, from which I distribute the
sub-repos, seems not so easily realisable with git?
A major restriction of git seems that the url's of each sub-repo need to
be unique, since they are in the global file .gitmodules? This seems strange
to me: If every submodule had its repo-specific pull-information, then still
by foreach-git-pull, where each pull has location-specific information, I
could achieve something.
Hm, is the way how this is supposed to work really to first do "git submodule init",
to get a false path to the sub-repo into config, and then to change that path?
Then I have that nonsensic information about the url in .gitmodules?
And I can't just push the whole thing to Github (as I would have hoped)?
There is also the old problem that config is not under version control.
So "submodule" would be just about substituting scripts which run through
a bunch of repos and call, e.g., git pull in each (but with a certain commit in mind)?
Anyway, if that's how it is, please just tell me.
(And perhaps the use-case is somehow convincing to a developer, and
somebody might think about adding "full" submodules.)
Thanks in any case!
Oliver
^ permalink raw reply
* Re: Tonight's pushout
From: Neal Kreitzinger @ 2010-12-08 21:35 UTC (permalink / raw)
To: git
In-Reply-To: <7v8w01m27t.fsf@alter.siamese.dyndns.org>
"prerelease freeze" is not in the git-workflows manpage. I'm interested in
how you-all do this because I use the git-workflows mangpage to help me
figure out my workflows. Can someone explain?
v/r,
Neal
"Junio C Hamano" <gitster@pobox.com> wrote in message
news:7v8w01m27t.fsf@alter.siamese.dyndns.org...
> All four main integration branches in tonight's pushout will pass tests if
> you drop three-tip commits from 'pu'. That might be just showing that
> there are some caps in the tests, but I am somewhat happier than usual.
>
> Tomorrow, I hopefully will start moving stuff out of 'next' to 'master',
> and 'pu' to 'next', in preparation for 1.7.4 prerelease freeze.
^ permalink raw reply
* Re: [RFC/PATCH] Re: git submodule -b ... of current HEAD fails
From: Jens Lehmann @ 2010-12-08 21:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, git, Klaus Ethgen, Sven Verdoolaege, mlevedahl
In-Reply-To: <7vipz5nqd0.fsf@alter.siamese.dyndns.org>
Am 07.12.2010 23:57, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Nope, these lines date back to the time before I got involved in the
>> submodule business ... Seems like this "git checkout" was added in
>> March 2008 by Mark Levedahl (CCed), maybe he can shed some light on
>> that.
>>
>> But to me your change looks good, so feel free to add:
>> Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
>
> Does either of you want to add a test for this?
Will do.
^ permalink raw reply
* Re: [PATCH] t9143: do not fail when unhandled.log.gz is not created
From: Eric Wong @ 2010-12-08 21:41 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git, Torsten Bögershausen
In-Reply-To: <4CFFB188.6000006@gmail.com>
Torsten Bögershausen <totte.enea@gmail.com> wrote:
> If you agree, I will send a V2 version of the patch, which
> will use the following:
> ---------------------------
> if test -r .git/svn/refs/remotes/git-svn/unhandled.log.gz
> then
> test_expect_success 'git svn gc produces a valid gzip file' '
> gunzip .git/svn/refs/remotes/git-svn/unhandled.log.gz
> '
> fi
Yes, it's definitely a better test. Thanks!
--
Eric Wong
^ permalink raw reply
* Re: Vendor branches workflow
From: Neal Kreitzinger @ 2010-12-08 21:54 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTi=s9p3RycRCrocHEzfc4L-pnU6S9xCKfEL7TP=i@mail.gmail.com>
"Leonid Podolny" <leonidp.lists@gmail.com> wrote in message
news:AANLkTi=s9p3RycRCrocHEzfc4L-pnU6S9xCKfEL7TP=i@mail.gmail.com...
> Hi, list,
> I would like an advice on organizing a vendor branch workflow, to
> minimize the risk of it biting me in the future.
> In our project, we have two upstreams, which are rather massively
> patched. One of the upstreams is an SF svn repository, the other
> arrives in form of tgz's with sources. Now git is tracking the patched
> version, and I want to add a vendor branch to simplify future vendor
> drops.
> Out of the SVN upstream, we use only specific directories.
> So, two questions:
> - How do I deal with unneeded directories? Do I filter them out before
> commiting to the vendor branch or while merging the vendor branch into
> the master?
> - Do you think it would be a good idea to keep .svn directories around
> at the vendor branch? (Kind of connected to the first question,
> because if I keep the .svn's, I will also have to keep the unneeded
> dirs).
The git-rm manpage explains a methodology for vendor branches. Maybe you've
already read it...
v/r,
Neal
^ 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