* Re: git-rebase skips automatically no more needed commits
From: Junio C Hamano @ 2011-09-06 17:09 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <CAC9WiBg9+30NjO+NKXVdBiWjR-HU2689JQqVY7Rk5+DM7MiNBg@mail.gmail.com>
Francis Moreau <francis.moro@gmail.com> writes:
> When rebasing my current branch onto the last master one, there're
> sometimes some commits which doesn't add anything anymore.
>
> Currently git-rebase produces the following message:
>
> nothing added to commit but untracked files present (use "git add" to track)
>
> Would it be possible to add a new option to this command so it simply
> skip the unneeded commit ?
Our assumption has always been that it is a notable event that a patch
that does not get filtered with internal "git cherry" (which culls patches
that are textually identical to those that are already merged to the
history you are rebasing onto) becomes totally unneeded and is safe to ask
for human confirmation in the form of "rebase --skip" than to ignore it
and give potentially incorrect result silently.
Obviously you do not find it a notable event for some reason. We would
need to understand why, and if the reason is sensible, it _might_ make
sense to allow a user to say "git rebase --ignore-merged" or something
when starting the rebase.
^ permalink raw reply
* Re: [RFC/PATCH git] http: avoid empty error messages for some curl errors
From: Junio C Hamano @ 2011-09-06 17:02 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: Jonathan Nieder, git, Tay Ray Chuan
In-Reply-To: <alpine.DEB.2.00.1109061023010.3841@tvnag.unkk.fr>
Daniel Stenberg <daniel@haxx.se> writes:
> On Mon, 5 Sep 2011, Jonathan Nieder wrote:
>
>> + if (!curl_errorstr[0])
>> + strlcpy(curl_errorstr,
>> + curl_easy_strerror(results.curl_result),
>> + sizeof(curl_errorstr));
>
> (as libcurl hacker)
>
> For the record, in libcurl we work on providing "extra" information in
> the error buffer when there is additional info to provide that would
> help. In some cases we deem there isn't (or we just to provide any)
> and then the generic error message is good enough and could indeed be
> used like this...
Sorry if I am a bit slow but are you saying:
(1) we provide "extra" but your patch is not using it which is bad?
(2) the above is Ok but there are better ways to do it?
(3) something else?
^ permalink raw reply
* Re: [PATCH v2 1/5] sha1_file cleanup: remove redundant variable check
From: Junio C Hamano @ 2011-09-06 16:59 UTC (permalink / raw)
To: Wang Hui; +Cc: git, tali
In-Reply-To: <1315304645-12009-2-git-send-email-Hui.Wang@windriver.com>
Wang Hui <Hui.Wang@windriver.com> writes:
> From: Hui Wang <Hui.Wang@windriver.com>
>
> This variable check is always true, so it is redundant and need to be
> removed.
>
> We can't remove the init value for this variable, since removing
> it will introduce building warning:
> 'base_len' may be used uninitialized in this function.
If we are into cleaning things up, we should instead notice and say "yuck"
to the repeated "is entry is absolute and relative base is given" check.
Wouldn't something like this makes things easier to follow and also avoids
the "when does the path normalized and made absolute" issue?
Completely untested and I may have off-by-one errors and such, but I think
you would get the idea...
sha1_file.c | 29 ++++++++++++-----------------
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index e002056..26aa3be 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -248,27 +248,22 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
const char *objdir = get_object_directory();
struct alternate_object_database *ent;
struct alternate_object_database *alt;
- /* 43 = 40-byte + 2 '/' + terminating NUL */
- int pfxlen = len;
- int entlen = pfxlen + 43;
- int base_len = -1;
+ int pfxlen, entlen;
+ struct strbuf pathbuf = STRBUF_INIT;
if (!is_absolute_path(entry) && relative_base) {
- /* Relative alt-odb */
- if (base_len < 0)
- base_len = strlen(relative_base) + 1;
- entlen += base_len;
- pfxlen += base_len;
+ strbuf_addstr(&pathbuf, relative_base);
+ strbuf_addch(&pathbuf, '/');
}
- ent = xmalloc(sizeof(*ent) + entlen);
+ strbuf_add(&pathbuf, entry, len);
+ normalize_path_copy(pathbuf.buf, pathbuf.buf);
+ strbuf_setlen(&pathbuf, strlen(pathbuf.buf));
- if (!is_absolute_path(entry) && relative_base) {
- memcpy(ent->base, relative_base, base_len - 1);
- ent->base[base_len - 1] = '/';
- memcpy(ent->base + base_len, entry, len);
- }
- else
- memcpy(ent->base, entry, pfxlen);
+ pfxlen = pathbuf.len;
+ entlen = pfxlen + 43; /* '/' + 2 hex + '/' + 38 hex + NUL */
+ ent = xmalloc(sizeof(*ent) + entlen);
+ memcpy(ent->base, pathbuf.buf, pfxlen);
+ strbuf_release(&pathbuf);
ent->name = ent->base + pfxlen + 1;
ent->base[pfxlen + 3] = '/';
^ permalink raw reply related
* Re: [BUG] git bisect start fails when stale bisect data is left behind
From: Junio C Hamano @ 2011-09-06 16:38 UTC (permalink / raw)
To: Christian Couder; +Cc: Joel Kaasinen, git
In-Reply-To: <CAP8UFD1h059dOyjszcP-qFauyho78c0RHBMQsGOPFgzZtp+7vg@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
>> How to reproduce:
>> $ echo foo > .git/BISECT_START
>> $ git bisect start HEAD HEAD^
>>
>> Fails with "fatal: invalid reference:" on git 1.7.6.
>
> Yeah, it looks like a very old behavior.
> I'd suggest a simple improvement in the error message like this:
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index c21e33c..bd7155b 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -67,7 +67,8 @@ bisect_start() {
> then
> # Reset to the rev from where we started.
> start_head=$(cat "$GIT_DIR/BISECT_START")
> - git checkout "$start_head" -- || exit
> + git checkout "$start_head" -- ||
> + die "Could not checkout previous start point
> '$start_head'. Try 'git bisect reset <branch>' first."
I do not necessarily think this is a bug to begin with --- the user had a
bad state, and bisect stopped without doing further damage.
The real question is what the sensible suggestion/advice the new message
should give. It would have to involve bisect reset in the end to get rid
of the stale bisect state, but wouldn't the user potentially lose some
other state if s/he blindly followed the die message's suggestion and ran
"bisect reset"?
^ permalink raw reply
* Re: [PATCH v2 3/5] sha1_file: improve directories comparison method
From: Junio C Hamano @ 2011-09-06 16:32 UTC (permalink / raw)
To: Wang Hui; +Cc: git, tali
In-Reply-To: <1315304645-12009-4-git-send-email-Hui.Wang@windriver.com>
Wang Hui <Hui.Wang@windriver.com> writes:
> From: Hui Wang <Hui.Wang@windriver.com>
>
> In the past, to check if two directory paths are same, we use memcmp()
> to directly compare their path strings, this method can't get an
> accurate result if paths include ".." or "." or redundant slash, e.g.
> current dir is /, "/a/b/c", "/a/b//c/d/e/../.." and "./a/b/f/../c"
> should be the same dir, but current method will identify they are
> different.
>
> Now add a global function is_same_directory() to replace the old
> memcmp() method, this function will change two input paths to real
> path first, then normalized them and compare them.
I do not like this patch _at all_. While it may result in correct result
if you _always_ make it absolute before comparing two entities, if you
will be storing the normalized result after running the comparison anyway,
and if you are comparing against the existing and supposedly already
normalized entities with a new candidate, why would anybody sane would
want to keep paying for the normalization cost at such a low level?
IOW, you are proposing to do:
given a new candidate;
for existing entities:
normalize existing
normalize candiate
compare the above two
if they are equal:
ignore
if no match found
add the normalized candidate to the list
Wouldn't it make much more sense to do this:
given a new candidate;
normalize it
for existing entities:
compare existing and normalized candidate
there is no point in normalizing the existing one!
if they are equal:
ignore
if no match found
add the normalized candidate to the list
^ permalink raw reply
* Re: [PATCH v2 2/5] sha1_file: remove a buggy value setting
From: Junio C Hamano @ 2011-09-06 16:26 UTC (permalink / raw)
To: Wang Hui; +Cc: git, tali
In-Reply-To: <1315304645-12009-3-git-send-email-Hui.Wang@windriver.com>
Wang Hui <Hui.Wang@windriver.com> writes:
> From: Hui Wang <Hui.Wang@windriver.com>
>
> The ent->base[] is a character array, it has pfxlen characters from
> position 0 to (pfxlen-1) to contain an alt object dir name, the
> position pfxlen should be the string terminating character '\0' and
> is deliberately set to '\0' at the previous code line. The position
> (pfxlen+1) is given to ent->name.
Correct. Do you understand why?
We temporarily NUL terminate the ent->base[] so that we can give it to
is_directory() to see if that is a directory, but the invariants for a
alternate_object_database instance after it is properly initialized by
this function are to have:
- the directory name followed by a slash in the base[] array;
- the name pointer pointing at one byte beyond the slash;
- name[2] filled with a slash; and
- name[41] terminated with NUL.
Later, has_loose_object_nonlocal() calls fill_sha1_path() with the name
pointer to fill name[0..1, 3..40] with the hexadecimal representation of
the object name, which would result in base[] array to have the pathname
for a loose object found in that alternate. The same thing happens in
open_sha1_file() to read from a loose object in an alternate.
And you are breaking one of the above invariants by removing that slash
after the directory name. These callers of fill_sha1_path() will see the
directory name, your NUL, two hex, slash, and 38 hex in base[].
How would the code even work with your patch?
^ permalink raw reply
* Re: [PATCHv3 5/5] branch: allow pattern arguments
From: Michael J Gruber @ 2011-09-06 16:11 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Michael Schubert, git, Junio C Hamano, Jeff King
In-Reply-To: <CAGdFq_jmW+VZygVj73EP_1oB5DDNp5rYZgZq+i9zf3w6BpsMYA@mail.gmail.com>
Sverre Rabbelier venit, vidit, dixit 06.09.2011 16:26:
> Heya,
>
> On Tue, Sep 6, 2011 at 16:21, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> Have you ever tried to delete a remote branch?
>>
>> git branch -r -d origin/maint # workee
>> git branch -r -d remotes/origin/maint # no workee
>>
>> Without -r, it doesn't work either.
>
> Heh, I read this as "worktree" / "no worktree" at least 4 times.
>
Yes, our require_work_tree should really be renamed to
no_worktree_no_workee
The beauty of pidgin english ;)
Michael
^ permalink raw reply
* git-rebase skips automatically no more needed commits
From: Francis Moreau @ 2011-09-06 16:08 UTC (permalink / raw)
To: git
Hello,
When rebasing my current branch onto the last master one, there're
sometimes some commits which doesn't add anything anymore.
Currently git-rebase produces the following message:
nothing added to commit but untracked files present (use "git add" to track)
Would it be possible to add a new option to this command so it simply
skip the unneeded commit ?
Thanks
--
Francis
^ permalink raw reply
* Re: Question about right-only
From: Michael J Gruber @ 2011-09-06 16:08 UTC (permalink / raw)
To: mfwitten; +Cc: Tajti Ákos, git
In-Reply-To: <ec1404d75fd6461fa731f31625126884-mfwitten@gmail.com>
mfwitten@gmail.com venit, vidit, dixit 06.09.2011 17:24:
> On Tue, 06 Sep 2011 13:44:50 +0200, Tajti wrote:
>
>> what does the right-only option of git-log actually do? The manual is
>> not too verbose about it.
>
> The documentation is indeed a bit messy, so let me rearrange it for you.
>
> From `git help rev-parse':
>
> r1...r2 is called symmetric difference of r1 and r2 and is
> defined as `r1 r2 --not $(git merge-base --all r1 r2)'. It is
> the set of commits that are reachable from either one of r1 or
> r2 but not from both.
>
> Then we have this from `git help log':
>
> --left-right
> Mark which side of a symmetric diff a commit is reachable
> from. Commits from the left side [(r1 above)] are prefixed with
> < and those from the right [(r2 above)] with >...
>
> which should explain what `<' and `>' mean in the following from
> `git help log':
>
> --left-only, --right-only
> List only commits on the respective side of a symmetric
> range, i.e. only those which would be marked < resp. > by
> --left-right.
>
> This is probably most useful with the following option, described
> in `git help log':
>
> --cherry-pick
> Omit any commit that introduces the same change as another
> commit on the "other side" when the set of commits are
> limited with symmetric difference.
>
> ...
>
> For example, --cherry-pick --right-only A...B omits those
> commits from B which are in A or are patch-equivalent to a
> commit in A. In other words, this lists the + commits from
> git cherry A B. More precisely, --cherry-pick --right-only
> --no-merges gives the exact list.
>
> That is, you often run into multiple commit objects that are unique
> because of, say, differing commit dates, but that actually introduce
> the same change to the source; this combination of options is helpful
> in weeding out commits that introduce the same change.
>
> If you're still confused, don't hesitate to poke the list some more;
> the documentation is quite lacking over all topics, so don't feel
> stupid.
Feel free to improve it :)
Though, in this case, everything is in git-log's man page, except for
the definition of "symmetric range", which is a fundamental concept and
this described by git help revisions, e.g.
Would a pointer from --left-only,--right-only to --cherry-pick help?
Michael
^ permalink raw reply
* Re: [PATCH] send-email: add option -h
From: Junio C Hamano @ 2011-09-06 16:04 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20110906063236.GA4923@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> Just found a few more places, so how about this on top?
Yeah, something like that, except for git-send-email bits on side instead,
perhaps. There is no poing in adding a known bad version first and then
fix with a follow-up ;-).
Also I notice that "git-pull" parses "--help-all" but does not seem to do
anything useful (it gives the one-line "Usage: " message and exits with 0)
which probably deserves a patch separate from other commands.
^ permalink raw reply
* Re: Question about right-only
From: Tajti Ákos @ 2011-09-06 15:42 UTC (permalink / raw)
To: mfwitten; +Cc: git
In-Reply-To: <ec1404d75fd6461fa731f31625126884-mfwitten@gmail.com>
Thanks four your answer, it was really great help (cleared up everything)!
Best regards,
Ákos Tajti
2011.09.06. 17:24 keltezéssel, mfwitten@gmail.com írta:
> On Tue, 06 Sep 2011 13:44:50 +0200, Tajti wrote:
>
>> what does the right-only option of git-log actually do? The manual is
>> not too verbose about it.
> The documentation is indeed a bit messy, so let me rearrange it for you.
>
> From `git help rev-parse':
>
> r1...r2 is called symmetric difference of r1 and r2 and is
> defined as `r1 r2 --not $(git merge-base --all r1 r2)'. It is
> the set of commits that are reachable from either one of r1 or
> r2 but not from both.
>
> Then we have this from `git help log':
>
> --left-right
> Mark which side of a symmetric diff a commit is reachable
> from. Commits from the left side [(r1 above)] are prefixed with
> < and those from the right [(r2 above)] with>...
>
> which should explain what `<' and `>' mean in the following from
> `git help log':
>
> --left-only, --right-only
> List only commits on the respective side of a symmetric
> range, i.e. only those which would be marked< resp.> by
> --left-right.
>
> This is probably most useful with the following option, described
> in `git help log':
>
> --cherry-pick
> Omit any commit that introduces the same change as another
> commit on the "other side" when the set of commits are
> limited with symmetric difference.
>
> ...
>
> For example, --cherry-pick --right-only A...B omits those
> commits from B which are in A or are patch-equivalent to a
> commit in A. In other words, this lists the + commits from
> git cherry A B. More precisely, --cherry-pick --right-only
> --no-merges gives the exact list.
>
> That is, you often run into multiple commit objects that are unique
> because of, say, differing commit dates, but that actually introduce
> the same change to the source; this combination of options is helpful
> in weeding out commits that introduce the same change.
>
> If you're still confused, don't hesitate to poke the list some more;
> the documentation is quite lacking over all topics, so don't feel
> stupid.
^ permalink raw reply
* Re: Question about right-only
From: mfwitten @ 2011-09-06 15:24 UTC (permalink / raw)
To: Tajti Ákos; +Cc: git
In-Reply-To: <4E6607B2.2090000@intland.com>
On Tue, 06 Sep 2011 13:44:50 +0200, Tajti wrote:
> what does the right-only option of git-log actually do? The manual is
> not too verbose about it.
The documentation is indeed a bit messy, so let me rearrange it for you.
>From `git help rev-parse':
r1...r2 is called symmetric difference of r1 and r2 and is
defined as `r1 r2 --not $(git merge-base --all r1 r2)'. It is
the set of commits that are reachable from either one of r1 or
r2 but not from both.
Then we have this from `git help log':
--left-right
Mark which side of a symmetric diff a commit is reachable
from. Commits from the left side [(r1 above)] are prefixed with
< and those from the right [(r2 above)] with >...
which should explain what `<' and `>' mean in the following from
`git help log':
--left-only, --right-only
List only commits on the respective side of a symmetric
range, i.e. only those which would be marked < resp. > by
--left-right.
This is probably most useful with the following option, described
in `git help log':
--cherry-pick
Omit any commit that introduces the same change as another
commit on the "other side" when the set of commits are
limited with symmetric difference.
...
For example, --cherry-pick --right-only A...B omits those
commits from B which are in A or are patch-equivalent to a
commit in A. In other words, this lists the + commits from
git cherry A B. More precisely, --cherry-pick --right-only
--no-merges gives the exact list.
That is, you often run into multiple commit objects that are unique
because of, say, differing commit dates, but that actually introduce
the same change to the source; this combination of options is helpful
in weeding out commits that introduce the same change.
If you're still confused, don't hesitate to poke the list some more;
the documentation is quite lacking over all topics, so don't feel
stupid.
^ permalink raw reply
* [PATCH] date.c: Parse timezone with colon as separator
From: Haitao Li @ 2011-09-06 14:56 UTC (permalink / raw)
To: git, gitster; +Cc: Haitao Li
Timezone designators including additional separator (`:`) are ignored.
Actually zone designators in below formats are all valid according to
ISO8601:2004, section 4.3.2:
[+-]hh, [+-]hhmm, [+-]hh:mm
Steps to reproduce the issue this patch fixes:
$ mkdir /tmp/test
$ cd /tmp/test
$ git init
$ echo 'timezone' > file.txt
$ git add .
$ git update-index
$ git write-tree
3e168d57e1c32a4598af134430384f0587581503
# Commit the tree returned above. Give a date with colon separated
# timezone
$ echo "Test commit" | \
TZ=UTC GIT_AUTHOR_DATE='2011-09-03T12:34:56+08:00' \
git commit-tree 3e168d57e1c32a4598af134430384f0587581503 | \
xargs git show | grep Date
Date: Sat Sep 3 12:34:56 2011 +0000
while the expected result is:
Date: Sat Sep 3 12:34:56 2011 +0800
^---
This patch teaches git recognizing zone designators with hours and
minutes separated by colon, or minutes are empty.
Signed-off-by: Haitao Li <lihaitao@gmail.com>
---
date.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/date.c b/date.c
index 896fbb4..8a94944 100644
--- a/date.c
+++ b/date.c
@@ -556,15 +556,21 @@ static int match_tz(const char *date, int *offp)
int min, hour;
int n = end - date - 1;
- min = offset % 100;
- hour = offset / 100;
+ if (n == 2 && *end == ':') {
+ hour = offset;
+ offset = strtoul(date+4, &end, 10);
+ min = offset % 100;
+ } else {
+ hour = offset / 100;
+ min = offset % 100;
+ }
/*
- * Don't accept any random crap.. At least 3 digits, and
+ * Don't accept any random crap.. At least 2 digits, and
* a valid minute. We might want to check that the minutes
* are divisible by 30 or something too.
*/
- if (min < 60 && n > 2) {
+ if (min < 60 && n > 1) {
offset = hour*60+min;
if (*date == '-')
offset = -offset;
--
1.7.5.4
^ permalink raw reply related
* Re: git-svn and mergeinfo
From: Carlos Martín Nieto @ 2011-09-06 14:28 UTC (permalink / raw)
To: Bryan Jacobs; +Cc: Michael Haggerty, git
In-Reply-To: <20110906095256.205dd5d0@robyn.woti.com>
[-- Attachment #1: Type: text/plain, Size: 955 bytes --]
On Tue, 2011-09-06 at 09:52 -0400, Bryan Jacobs wrote:
> On Tue, 06 Sep 2011 14:56:38 +0200
> Carlos Martín Nieto <cmn@elego.de> wrote:
>
> > You can also save the mergeinfo to a file, add the line, and use
> > --mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but
> > blindly replacing every space with a newline is not always the right
> > option. If a merged directory contains a space, this change will break
> > the mergeinfo, even if you're properly quoting your variable or using
> > the $(cat /some/file) method.
> >
> > Cheers,
> > cmn
>
> Ah, a situation I neglected to consider! Perhaps we should revert this
> patch, since I worked up the initiative to write an
> auto-populating-mergeinfo patch for git-svn anyhow.
As it can cause regressions, I think reverting is the right option. And
since git-svn is going to learn to do it by itself, the functionality
isn't a big loss.
Cheers,
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCHv3 5/5] branch: allow pattern arguments
From: Sverre Rabbelier @ 2011-09-06 14:26 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Michael Schubert, git, Junio C Hamano, Jeff King
In-Reply-To: <4E662C6F.7000205@drmicha.warpmail.net>
Heya,
On Tue, Sep 6, 2011 at 16:21, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Have you ever tried to delete a remote branch?
>
> git branch -r -d origin/maint # workee
> git branch -r -d remotes/origin/maint # no workee
>
> Without -r, it doesn't work either.
Heh, I read this as "worktree" / "no worktree" at least 4 times.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCHv3 5/5] branch: allow pattern arguments
From: Michael J Gruber @ 2011-09-06 14:21 UTC (permalink / raw)
To: Michael Schubert; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <4E661BDE.1080204@elegosoft.com>
Michael Schubert venit, vidit, dixit 06.09.2011 15:10:
> On 08/28/2011 04:54 PM, Michael J Gruber wrote:
>> +static int match_patterns(const char **pattern, const char *refname)
>> +{
>> + if (!*pattern)
>> + return 1; /* no pattern always matches */
>> + while (*pattern) {
>> + if (!fnmatch(*pattern, refname, 0))
>> + return 1;
>> + pattern++;
>> + }
>> + return 0;
>> +}
>
> Nitpick: maybe builtin/branch.c and builtin/tag.c could share match_pattern().?
I think all commands which list refs should share code - for-each-ref,
branch, tag, replace. I suggest to unify log and for-each-ref-formats
first, the unify ref listers.
> A second thought: the printed "remotes/" prefix could be confusing for users,
> since it seems to be part of the refname. For example:
>
> $ git branch -a
> * master
> maint
> man
> remotes/origin/master
> remotes/origin/maint
> remotes/origin/man
>
> $ git branch -a --list remotes/origin*
> [no output]
>
> but
>
> $ git branch -a --list origin*
> remotes/origin/master
> remotes/origin/maint
> remotes/origin/man
>
> (Sorry in case I missed that) What's the reason you decided --list to show local
> branches only? Maybe --list could show all refnames without any extra prefix.?
I didn't decide anything here. "git branch" lists all local branches and
has been doing that forever, and "--list" is and should be a noop
without a pattern. That was the idea: -r/-a select refnames,
--list/-v/-vv activate the list mode(s), and the pattern is matched
against the selected refs.
(This is one reason why I didn't want it to be named --glob - the
pattern is a filter, not a selector.)
That being said, I find the fact that "-a --list remotes/origin/*" does
not match anything somewhat disconcerting, although it fits in with the
general idea of "git branch": it deals with branch names, not ref names.
Have you ever tried to delete a remote branch?
git branch -r -d origin/maint # workee
git branch -r -d remotes/origin/maint # no workee
Without -r, it doesn't work either.
So, the way it is it fits in with how "git branch" works, and is
different from for-each-ref (and rev-list --glob). I don't like it,
because you may have a local branch origin/maint (i.e.
refs/heads/origin/maint) which you can't distinguish from the remote
branch by a pattern, only by using or not using -r. But it's the same as
with "git branch -d", really.
Michael
^ permalink raw reply
* Re: [PATCH] git-svn: teach git-svn to populate svn:mergeinfo
From: Bryan Jacobs @ 2011-09-06 14:00 UTC (permalink / raw)
To: Eric Wong; +Cc: Sam Vilain, git
In-Reply-To: <20110903084947.GA16711@dcvr.yhbt.net>
On Sat, 3 Sep 2011 08:49:47 +0000
Eric Wong <normalperson@yhbt.net> wrote:
> dcommit needs to continually rebase because it's possible somebody
> else may make a commit to the SVN repo while a git-svn user is
> dcommiting and cause a conflict the user would need to resolve in the
> working tree.
>
> At least I think that was the reason... There is also the
> "commit-diff" command in git-svn. It was the precursor to dcommit
> which requires no changes to the working tree.
>
Let me see if I've got this right.
The goal here is to commit each x~..x for each x in A..B, aborting if
the SVN tree is not in state "x~" when the diff arrives.
"commit-diff" appears to be doing exactly what "dcommit" is doing, but
iteratively for each change in linearized A..B, rebasing after each
step. This sounds correct to me, assuming that the "apply_diff" method
will correctly abort if a commit races into the upstream SVN before it
is called. So why am I seeing files added in changes on alternate
branches ending up in the working copy when I abort before apply_diff
is called for the commit which merges them into the present branch?
You can check for this yourself with my patch using the example setup I
gave earlier. You'll see files in the present/untracked state - these
interfere with rebasing the user-created-but-not-SVN-dcommited merge
onto the partially-sent-to-SVN tree.
Bryan Jacobs
^ permalink raw reply
* Re: git-svn and mergeinfo
From: Bryan Jacobs @ 2011-09-06 13:52 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Michael Haggerty, git
In-Reply-To: <1315313800.9839.10.camel@bee.lab.cmartin.tk>
On Tue, 06 Sep 2011 14:56:38 +0200
Carlos Martín Nieto <cmn@elego.de> wrote:
> You can also save the mergeinfo to a file, add the line, and use
> --mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but
> blindly replacing every space with a newline is not always the right
> option. If a merged directory contains a space, this change will break
> the mergeinfo, even if you're properly quoting your variable or using
> the $(cat /some/file) method.
>
> Cheers,
> cmn
Ah, a situation I neglected to consider! Perhaps we should revert this
patch, since I worked up the initiative to write an
auto-populating-mergeinfo patch for git-svn anyhow.
Bryan Jacobs
^ permalink raw reply
* Re: [PATCHv3 5/5] branch: allow pattern arguments
From: Michael Schubert @ 2011-09-06 13:10 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <0c487086643fbf0334140365f20fef62242b7dac.1314543252.git.git@drmicha.warpmail.net>
On 08/28/2011 04:54 PM, Michael J Gruber wrote:
> +static int match_patterns(const char **pattern, const char *refname)
> +{
> + if (!*pattern)
> + return 1; /* no pattern always matches */
> + while (*pattern) {
> + if (!fnmatch(*pattern, refname, 0))
> + return 1;
> + pattern++;
> + }
> + return 0;
> +}
Nitpick: maybe builtin/branch.c and builtin/tag.c could share match_pattern().?
A second thought: the printed "remotes/" prefix could be confusing for users,
since it seems to be part of the refname. For example:
$ git branch -a
* master
maint
man
remotes/origin/master
remotes/origin/maint
remotes/origin/man
$ git branch -a --list remotes/origin*
[no output]
but
$ git branch -a --list origin*
remotes/origin/master
remotes/origin/maint
remotes/origin/man
(Sorry in case I missed that) What's the reason you decided --list to show local
branches only? Maybe --list could show all refnames without any extra prefix.?
Thanks.
^ permalink raw reply
* Re: git-svn and mergeinfo
From: Carlos Martín Nieto @ 2011-09-06 12:56 UTC (permalink / raw)
To: Bryan Jacobs; +Cc: Michael Haggerty, git
In-Reply-To: <20110901104327.14d4dba6@robyn.woti.com>
[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]
On Thu, 2011-09-01 at 10:43 -0400, Bryan Jacobs wrote:
> On Thu, 01 Sep 2011 10:59:51 +0200
> Michael Haggerty <mhagger@alum.mit.edu> wrote:
>
> > On 08/29/2011 07:20 PM, Bryan Jacobs wrote:
> > > I have been (ab)using git-svn for committing to a central SVN
> > > repository while doing my work locally with git. To this end, I've
> > > written a set of scripts and hooks which perform squash merges
> > > locally and then dcommit them with proper svn:mergeinfo
> > > annotations. The final result is the perfect appearance of having
> > > done a native SVN merge in the central repository, while using only
> > > local git commands and gaining the full benefit of git's conflict
> > > resolution and developer convenience.
> > >
> > > However, to make this work with git 1.7.6, I needed to make *one*
> > > change to the git internals: --merge-info does not allow setting
> > > mergeinfo for more than one branch. Because it's a complete
> > > overwrite operation instead of an update, this is a serious issue
> > > preventing its use for nontrivial branches.
> > >
> > > Might I suggest adding a block like the following around line 552 of
> > > git-svn?
> > >
> > > if (defined($_merge_info))
> > > {
> > > $_merge_info =~ tr{ }{\n};
> > > }
> >
> > Naive question: why can't you pass a newline (properly quoted, of
> > course) directly within the string argument to the --mergeinfo option?
>
> The only way I know of to do that in bash is to assign the
> newline-bearing string to a variable, and then use the variable in a
> command line option. Extremely awkward.
You can also save the mergeinfo to a file, add the line, and use
--mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but
blindly replacing every space with a newline is not always the right
option. If a merged directory contains a space, this change will break
the mergeinfo, even if you're properly quoting your variable or using
the $(cat /some/file) method.
Cheers,
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH git] http: avoid empty error messages for some curl errors
From: Daniel Stenberg @ 2011-09-06 12:20 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Tay Ray Chuan
In-Reply-To: <20110905222202.GA32071@elie>
On Mon, 5 Sep 2011, Jonathan Nieder wrote:
> + if (!curl_errorstr[0])
> + strlcpy(curl_errorstr,
> + curl_easy_strerror(results.curl_result),
> + sizeof(curl_errorstr));
(as libcurl hacker)
For the record, in libcurl we work on providing "extra" information in the
error buffer when there is additional info to provide that would help. In some
cases we deem there isn't (or we just to provide any) and then the generic
error message is good enough and could indeed be used like this...
--
/ daniel.haxx.se
^ permalink raw reply
* Question about right-only
From: Tajti Ákos @ 2011-09-06 11:44 UTC (permalink / raw)
To: git@vger.kernel.org
Dear List,
what does the right-only option of git-log actually do? The manual is
not too verbose about it.
Thanks in advance,
Ákos Tajti
^ permalink raw reply
* Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.
From: Nix @ 2011-09-06 11:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Clemens Buchacher, Sverre Rabbelier, git
In-Reply-To: <4E65F842.7080601@viscovery.net>
On 6 Sep 2011, Johannes Sixt stated:
> Am 9/6/2011 12:25, schrieb Nix:
>> OK, I'll add range checking support then!
>
> Don't forget to follow this advice noted on the POSIX page
> (http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html):
>
> Since 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX} are
> returned on error and are also valid returns on success, an application
> wishing to check for error situations should set errno to 0, then call
> strtol() or strtoll(), then check errno.
Oh, I've fallen into *that* trap before with math functions setting
ERANGE/EDOM. Thanks for the reminder :)
--
NULL && (void)
^ permalink raw reply
* Re: user permission / authority
From: Carlos Martín Nieto @ 2011-09-06 10:45 UTC (permalink / raw)
To: ian; +Cc: git
In-Reply-To: <1315303980991-6763296.post@n2.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Tue, 2011-09-06 at 03:13 -0700, ian wrote:
> I could not find user permission or authority level. Thatis, I can restrict a
> user not to use the 'commit' function for example. Seems that everyone
> having GIT & TortoiseGIT can do any of the functions. Is there a way (or any
> other GUI)that enables these restrictions by user?
Not as far as I know, but this isn't necessary. Git is a distributed
system, so any changes that an user does only exist in their local
repository until they push the changes out to some other repository, and
with gitolite[0] you can restrict who can push to which branches.
If you just want people to be able to browse the repository, maybe
installing gitweb or cgit would fit your needs better.
[0] https://github.com/sitaramc/gitolite
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.
From: Johannes Sixt @ 2011-09-06 10:38 UTC (permalink / raw)
To: Nix; +Cc: Clemens Buchacher, Sverre Rabbelier, git
In-Reply-To: <87liu2j7c3.fsf@spindle.srvr.nix>
Am 9/6/2011 12:25, schrieb Nix:
> OK, I'll add range checking support then!
Don't forget to follow this advice noted on the POSIX page
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html):
Since 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX} are
returned on error and are also valid returns on success, an application
wishing to check for error situations should set errno to 0, then call
strtol() or strtoll(), then check errno.
-- Hannes
^ 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