Junio C Hamano writes:
> Call init_revisions() first to prepare the revision traversal
> parameters and pass it to git_log_config(), so that necessary bits
> in the traversal parameters can be tweaked before we call the
> command line parsing infrastructure setup_revisions() from
> the cmd_log_in
Hi Philip and all,
let me explain in full what is the problem that I tried to solve, and
how along the way I stumbled in something that seems to me a git bug
(at least a documentation one).
There is an R&D team developing software using a workflow that is
similar to the integerator-manager one (t
On Thu, Oct 4, 2012 at 1:01 PM, Junio C Hamano wrote:
> Perhaps the wildmatch code may not be what we want X-<.
When I imported wildmatch I was hoping to make minimum changes to it.
But wildmatch is probably the only practical way to support "**" even
if we later need to change it the way we want
We're going to add more attributes to u.pattern so it'll become bigger
in size than a pointer. There's no point in sharing the same room with
u.attr.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
attr.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/att
Signed-off-by: Nguyễn Thái Ngọc Duy
---
attr.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/attr.c b/attr.c
index 48df800..66b96d9 100644
--- a/attr.c
+++ b/attr.c
@@ -277,6 +277,7 @@ static struct match_attr *parse_attr_line(const char *line,
const char *src,
stat
Signed-off-by: Nguyễn Thái Ngọc Duy
---
attr.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/attr.c b/attr.c
index 66b96d9..eb576ac 100644
--- a/attr.c
+++ b/attr.c
@@ -644,13 +644,11 @@ static void prepare_attr_stack(const char *path)
}
static int path_
.gitattributes and .gitignore share the same pattern syntax but has
separate matching implementation. Over the years, ignore's
implementation accumulates more optimizations while attr's stays the
same.
This patch adds those optimizations to .gitattributes. Basically it
tries to avoid fnmatch/wildm
"**" can match slashes, not like "*". "ab**ef" should be able to match
"ab/cd/ef", or "ab/c/d/ef" and so on. Turn off the EXC_FLAG_NODIR in
this case otherwise the pattern is only checked against the base
name. This behavior is in sync with rsync.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Document
"**" currently matches any characters including slashes. It's probably
too powerful. A more sensible definition may be match any characters
that the but the whole match must be wrapped by slashes. So "**" can
match none, "/", "/aaa/", "/aa/bb/" and so on but not "aa/bb".
Note it in the test suite.
On Thu, Oct 04, 2012 at 01:54:47AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Hmm. It seems like we should not need to open the tags at all. The main
> > reason is to produce the "peeled" advertisement just after it. But for a
> > packed ref with a modern version of git that supports the "peeled"
>
When we are asked to peel a ref to a sha1, we internally call
deref_tag, which will recursively parse each tagged object
until we reach a non-tag. This has the benefit that we will
verify our ability to load and parse the pointed-to object.
However, there is a performance downside: we may not need
The idea of the peel_ref function is to dereference tag
objects recursively until we hit a non-tag, and return the
sha1. Conceptually, it should return 0 if it is successful
(and fill in the sha1), or -1 if there was nothing to peel.
However, the current behavior is much more confusing. For a
regu
The point of peel_ref is to dereference tags; if the base
object is not a tag, then we can return early without even
loading the object into memory.
This patch accomplishes that by checking sha1_object_info
for the type. For a packed object, we can get away with just
looking in the pack index. For
When upload-pack advertises refs, we attempt to peel tags
and advertise the peeled version. We currently hand-roll the
tag dereferencing, and use as many optimizations as we can
to avoid loading non-tag objects into memory.
Not only has peel_ref recently learned these optimizations,
too, but it al
On Thu, Oct 04, 2012 at 03:56:09AM -0400, Jeff King wrote:
> [1/4]: peel_ref: use faster deref_tag_noverify
> [2/4]: peel_ref: do not return a null sha1
> [3/4]: peel_ref: check object type before loading
> [4/4]: upload-pack: use peel_ref for ref advertisements
I included my own timings
On Wed, Oct 03, 2012 at 06:33:36PM -0700, Junio C Hamano wrote:
> diff --git a/revision.c b/revision.c
> index a09e60b..7f5e53b 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -1604,12 +1604,12 @@ static int handle_revision_opt(struct rev_info *revs,
> int argc, const char **arg
> } else
On Wed, Oct 03, 2012 at 06:33:37PM -0700, Junio C Hamano wrote:
> When we added the "--perl-regexp" option (or "-P") to "git grep", we
> should have done the same for the commands in the "git log" family,
> but somehow we forgot to do so. This corrects it.
>
> Also introduce the "--basic-regexp"
On Wed, Oct 03, 2012 at 06:33:39PM -0700, Junio C Hamano wrote:
> Read grep.extendedregexp, grep.patterntype, etc. from the
> configuration so that "log --grep=''" honors the user
> preference without an explicit -P from the command line.
>
> Now that the callback parameter, which was so far unus
On Wednesday, 3 October 2012 at 9:20 AM, Junio C Hamano wrote:
>
> * fa/remote-svn (2012-09-19) 16 commits
> - Add a test script for remote-svn
> - remote-svn: add marks-file regeneration
> - Add a svnrdump-simulator replaying a dump file for testing
> - remote-svn: add incremental import
> - re
David Michael Barr wrote:
> On Wednesday, 3 October 2012 at 9:20 AM, Junio C Hamano wrote:
>> * fa/remote-svn (2012-09-19) 16 commits
>> - Add a test script for remote-svn
>> - remote-svn: add marks-file regeneration
>> - Add a svnrdump-simulator replaying a dump file for testing
>> - remote-svn:
On Thu, Oct 4, 2012 at 10:04 AM, Jeff King wrote:
> On Thu, Oct 04, 2012 at 03:56:09AM -0400, Jeff King wrote:
>
>> [1/4]: peel_ref: use faster deref_tag_noverify
>> [2/4]: peel_ref: do not return a null sha1
>> [3/4]: peel_ref: check object type before loading
>> [4/4]: upload-pack: use p
On 10/03/2012 08:17 PM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> There's an interesting case: "**foo". According to our rules, that
>> pattern does not contain slashes therefore is basename match. But some
>> might find that confusing because "**" can match slashes,...
>
> By "o
On Thu, Oct 4, 2012 at 4:34 PM, Michael Haggerty wrote:
On Thu, Oct 4, 2012 at 4:34 PM, Michael Haggerty wrote:
> Given that there is no obvious interpretation for what a construct like
> "x**y" would mean, and many plausible guesses (most of which sound
> rather useless), I suggest that we forbi
On Thu, Oct 4, 2012 at 5:01 PM, Ævar Arnfjörð Bjarmason
wrote:
> $ time (echo | ~/g/git/git-upload-pack . | pv >/dev/null)
Totally off-topic, but ...
Thanks for making me look up what pv is. I remember checking it out
quiet sometime
ago and have forgotten about it altogether.
Now I can
- Original Message -
> From: "Jonathan Nieder"
> Sent: Thursday, October 4, 2012 4:30:01 AM
> Subject: Re: fa/remote-svn (Re: What's cooking in git.git (Oct 2012, #01;
> Tue, 2))
>
> > > * fa/remote-svn (2012-09-19) 16 commits
> > > - Add a test script for remote-svn
> > > - remote-svn:
On Thu, Oct 4, 2012 at 3:07 AM, Angelo Borsotti
wrote:
...
> The operation that caused problems was nr. 4. In all the cases
> enlisted above, a git commit creates a brand new and unique commit
> because either it has a parent that is different from that of any
> other commit, or because its tree i
Hi,
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version 1.7.12 is much quicker:
markus@x4 linux % time git pull
Already up-to-date.
git pull 0.10s user 0.02s sy
Hi,
Is it normal that "git commit --amen" actually works ?
(it does like --amend)
version 1.7.10.4
®om
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 4, 2012 at 12:35 AM, John Whitney wrote:
> I just ran into a problem that I'm pretty sure is a bug in git. Just read
> and run this (fairly trivial) shell script to replicate.
When you added "* text=auto" in the .gitattributes file, you changed
what git considers to be the checked-in
> Is it normal that "git commit --amen" actually works ?
> (it does like --amend)
>
> version 1.7.10.4
Yes. From Documentation/technical/api-parse-options.txt:
* Long options may be 'abbreviated', as long as the abbreviation
is unambiguous.
Apparently since 2008-06-22.
So 'git commit
Great !
Thank you for your answer ;-)
It does not seem to work with git diff:
git diff --cache #missing d
git diff --cumulativ #missing e
®om
Le 2012-10-04 16:25, Phil Hord a écrit :
Is it normal that "git commit --amen" actually works ?
(it does like --amend)
version 1.7.10.4
Yes. Fro
On Thu, Oct 4, 2012 at 4:38 PM, Romain Vimont (®om) wrote:
> Great !
> Thank you for your answer ;-)
>
> It does not seem to work with git diff:
> git diff --cache #missing d
> git diff --cumulativ #missing e
This is because git-diff doesn't yet use the parse-options API, but
instead does ad-
On 10/03/2012 06:35 PM, Alexander Kostikov wrote:
That allows you can go back to the pre-rebase state by
"rebase --abort".
rebase --abort command were not available. I guess rebase file was not created.
I meant "rebase --abort" would be available *if* the error was caught by
"rebase". But in yo
On 10/04/2012 01:46 PM, Nguyen Thai Ngoc Duy wrote:
> On Thu, Oct 4, 2012 at 4:34 PM, Michael Haggerty wrote:
>> As for the implementation, it is quite easy to textually convert a glob
>> pattern, including "**" parts, into a regexp.
>
> Or we could introduce regexp syntax as an alternative and l
On 10/04/2012 12:35 AM, John Whitney wrote:
I just ran into a problem that I'm pretty sure is a bug in git. Just
read and run this (fairly trivial) shell script to replicate.
I tried your steps on a Mac, but I wasn't able to produce the issue.
Perhaps I don't have the right CRLF configs to trigg
Phil,
Thank you for your response. I do see the dilemma, but having
no possible "unmodified" state is extremely inconvenient and,
as shown, breaks basic git operations.
I guess my thought is that if git doesn't allow CRs to be checked
in, then it should strip the CRs when checking the file out,
Andrew,
Thanks for checking this on your machine.
This problem occurs on Mac, Windows, and Linux, and
with multiple versions of git. Note that in my script a CR
is appended to test.txt. On the Mac, you can generate this
in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
just download and
David Michael Barr writes:
> On Wednesday, 3 October 2012 at 9:20 AM, Junio C Hamano wrote:
>>
>> * fa/remote-svn (2012-09-19) 16 commits
>> ...
>>
>> A GSoC project.
>> Waiting for comments from mentors and stakeholders.
>
> I have reviewed this topic and am happy with the design and implemen
Andrew,
I forgot to say that all of the config settings
are not changed from the default.
---John
On 10/4/12 11:16 AM, John Whitney wrote:
Andrew,
Thanks for checking this on your machine.
This problem occurs on Mac, Windows, and Linux, and
with multiple versions of git. Note that in my
Stephen Bash writes:
> I seemed to have missed the GSoC wrap up conversation... (links happily
> accepted).
I also seem to have missed such conversation, if anything like that
happened. It certainly would have been nice for the mentors and the
student for each project to give us a two-to-three-
Michael Haggerty writes:
> On 10/03/2012 08:17 PM, Junio C Hamano wrote:
>>
>> What is the semantics of ** in the first place? Is it described to
>> a reasonable level of detail in the documentation updates? For
>> example does "**foo" match "afoo", "a/b/foo", "a/bfoo", "a/foo/b",
>> "a/bfoo/c
Jeff King writes:
>> +} else if (!strcmp(arg, "--perl-regexp") || !strcmp(arg, "-P")) {
>> +grep_set_pattern_type_option(GREP_PATTERN_TYPE_PCRE,
>> &revs->grep_filter);
>
> Do we want to yield short-and-sweet "-P" to perl-regexp? git-grep does
> so to match GNU grep, but we are n
Jeff King writes:
> Hmm. So I think this is a nice feature for some people, but I wonder if
> we would run into any plumbing compatibility issues. People do tend to
> use "log" as plumbing (since rev-list is not as capable). On the other
> hand, I'd think most internal uses of "log --grep" would
Phil Hord writes:
>> Is it normal that "git commit --amen" actually works ?
>> (it does like --amend)
>>
>> version 1.7.10.4
>
> Yes. From Documentation/technical/api-parse-options.txt:
>
> * Long options may be 'abbreviated', as long as the abbreviation
> is unambiguous.
>
> Apparentl
Erik Faye-Lund writes:
> On Thu, Oct 4, 2012 at 4:38 PM, Romain Vimont (®om) wrote:
>> Great !
>> Thank you for your answer ;-)
>>
>> It does not seem to work with git diff:
>> git diff --cache #missing d
>> git diff --cumulativ #missing e
>
> This is because git-diff doesn't yet use the par
On 10/04/2012 12:16 PM, John Whitney wrote:
This problem occurs on Mac, Windows, and Linux, and
with multiple versions of git. Note that in my script a CR
is appended to test.txt. On the Mac, you can generate this
in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
just download and run the
Junio C Hamano writes:
> Phil Hord writes:
>
>>> Is it normal that "git commit --amen" actually works ?
>>> (it does like --amend)
>>>
>>> version 1.7.10.4
>>
>> Yes. From Documentation/technical/api-parse-options.txt:
>>
>> * Long options may be 'abbreviated', as long as the abbreviation
>
My `.git/config` can be corrupted if I try to get a local branch with
an extremely long name to track a remote branch.
Here is a (contrived) example to reproduce the issue:
$ cd /tmp
$ mkdir buggyrepo otherrepo
$ cd buggyrepo/ && git init && cd -
$ cd otherrepo/ && git init && cd
Nguyễn Thái Ngọc Duy writes:
> On Thu, Oct 4, 2012 at 1:01 PM, Junio C Hamano wrote:
>> Perhaps the wildmatch code may not be what we want X-<.
>
> When I imported wildmatch I was hoping to make minimum changes to it.
> But wildmatch is probably the only practical way to support "**" even
> if w
From: Simon Ruderich
Signed-off-by: Simon Ruderich
Signed-off-by: Ralf Thielow
---
po/de.po | 14 +++---
1 Datei geändert, 7 Zeilen hinzugefügt(+), 7 Zeilen entfernt(-)
diff --git a/po/de.po b/po/de.po
index a3cf695..9e9f2da 100644
--- a/po/de.po
+++ b/po/de.po
@@ -55,7 +55,7 @@ msgst
Nguyễn Thái Ngọc Duy writes:
> - if (!strchr(p, '/'))
> + if (!strchr(p, '/') && !strstr(p, "**"))
Doesn't wildmatch allow these to be quoted, similar to the way usual
glob works, e.g.
$ >ff
$ >\?f
$ echo ??
?f ff
$ echo \?f
On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Hmm. So I think this is a nice feature for some people, but I wonder if
> > we would run into any plumbing compatibility issues. People do tend to
> > use "log" as plumbing (since rev-list is not as capable
Nguyễn Thái Ngọc Duy writes:
> "**" currently matches any characters including slashes. It's probably
> too powerful. A more sensible definition may be match any characters
> that the but the whole match must be wrapped by slashes. So "**" can
> match none, "/", "/aaa/", "/aa/bb/" and so on but n
In particular, gcc complains thus:
CC pretty.o
pretty.c: In function 'format_commit_item':
pretty.c:1282: warning: 'offset' might be used uninitialized in \
this function
In order to suppress the warning we simply initialize the 'offset'
variable in it's declarartion.
Si
Jeff King writes:
> When we are asked to peel a ref to a sha1, we internally call
> deref_tag, which will recursively parse each tagged object
> until we reach a non-tag. This has the benefit that we will
> verify our ability to load and parse the pointed-to object.
>
> However, there is a perfor
On Thu, Oct 04, 2012 at 01:15:25PM -0400, Ben Olive wrote:
> My `.git/config` can be corrupted if I try to get a local branch with
> an extremely long name to track a remote branch.
>
> Here is a (contrived) example to reproduce the issue:
>
>
> $ cd /tmp
> $ mkdir buggyrepo otherrepo
>
Jeff King writes:
> The idea of the peel_ref function is to dereference tag
> objects recursively until we hit a non-tag, and return the
> sha1. Conceptually, it should return 0 if it is successful
> (and fill in the sha1), or -1 if there was nothing to peel.
>
> However, the current behavior is
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
> with current trunk I get the following on an up-to-date Linux tree:
>
> markus@x4 linux % time git pull
> Already up-to-date.
> git pull 7.84s user 0.26s system 92% cpu 8.743 total
>
> git version 1.7.12 is much quicker:
>
Hi Phil,
\>
> And why is this a problem?
>
> Is there a process or person watching the server for a new commit?
>
> Is it not enough to notice that the pushed-to branch has a new HEAD?
>
Yes, the developers use the git gui to see the graph of branches and commits.
The simpler and uniform it is, t
Jeff King writes:
> The point of peel_ref is to dereference tags; if the base
> object is not a tag, then we can return early without even
> loading the object into memory.
>
> This patch accomplishes that by checking sha1_object_info
> for the type. For a packed object, we can get away with just
Jeff King writes:
> On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > Hmm. So I think this is a nice feature for some people, but I wonder if
>> > we would run into any plumbing compatibility issues. People do tend to
>> > use "log" as plumbing (sinc
On 2012.10.04 at 14:43 -0400, Jeff King wrote:
> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>
> > with current trunk I get the following on an up-to-date Linux tree:
> >
> > markus@x4 linux % time git pull
> > Already up-to-date.
> > git pull 7.84s user 0.26s system 92%
Ben Olive writes:
> My `.git/config` can be corrupted if I try to get a local branch with
> an extremely long name to track a remote branch.
>
> Here is a (contrived) example to reproduce the issue:
Don't do that, then ;-)
I think we have a change that is already cooking.
Ben (Walton), want to
Jeff King writes:
> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>
>> with current trunk I get the following on an up-to-date Linux tree:
>>
>> markus@x4 linux % time git pull
>> Already up-to-date.
>> git pull 7.84s user 0.26s system 92% cpu 8.743 total
>>
>> git versi
On Thu, Oct 04, 2012 at 12:06:16PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The point of peel_ref is to dereference tags; if the base
> > object is not a tag, then we can return early without even
> > loading the object into memory.
> >
> > This patch accomplishes that by checking
Jeff King writes:
> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>
>> with current trunk I get the following on an up-to-date Linux tree:
>>
>> markus@x4 linux % time git pull
>> Already up-to-date.
>> git pull 7.84s user 0.26s system 92% cpu 8.743 total
>>
>> git versi
I'm not sure to follow everything... But looks like:
$ git add -p
or
$ git add -i
should do what you want, no?
You select the hunks to commit, let over the "hacks" and then
$ git commit
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imaginatio
Jeff King writes:
> [1] One thing I've been toying is with "external alternates"; dumping
> your large objects in some realtively slow data store (e.g., a
> RESTful HTTP service). You could cache and cheaply query a list of
> "sha1 / size / type" for each object from the store, but ge
Junio C Hamano writes:
> It gets more curious, though.
> ...
> However.
>
> If I revert 5802f81 that updated the implementation of fmt-merge-msg
> on top of 'master', *without* reverting 34f5130^2, I get ~4.5 seconds.
> As we are doing an "Already up-to-date" pull, I thought there is no
> need to
Sorry, I didn't realize that there is a display mode where the
list of files is empty, not even showing a "Comments" entry.
Here's a patch that fixes it, plus another patch that is only related
in so far as the bug that it fixes was introduced by the same commit.
[PATCH 1/2] gitk: Fix error messa
When clicking on the line that connects two commit nodes, gitk
would bring up an error dialog saying "can't read "cflist_top":
no such variable".
This fixes a regression that was introduced with b967135 ("gitk:
Synchronize highlighting in file view when scrolling diff").
Signed-off-by: Stefan Hal
This fixes another regression that was introduced in b967135 ("gitk:
Synchronize highlighting in file view when scrolling diff"): when
searching for a string in tree mode, jumping to the next search hit
would highlight the "Comments" entry in the file list.
Signed-off-by: Stefan Haller
---
gitk
> Having the
> last page of that output should give us enough context as to where it's
> failing.
Full script is uploaded to
https://dl.dropbox.com/u/10828740/rebase.log Here is the last page:
---[code]
if test -s "$dotest"/rewritten; then
git notes copy --for-r
Jeff King writes:
> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>
>> with current trunk I get the following on an up-to-date Linux tree:
>>
>> markus@x4 linux % time git pull
>> Already up-to-date.
>> git pull 7.84s user 0.26s system 92% cpu 8.743 total
>>
>> git versi
Junio C Hamano writes:
> Jeff King writes:
>
>> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>>
>>> with current trunk I get the following on an up-to-date Linux tree:
>>>
>>> markus@x4 linux % time git pull
>>> Already up-to-date.
>>> git pull 7.84s user 0.26s system 9
> rebase -i fails with different error:
Also in case of rebase -i the branch pointer is not changed. Thus
nothing to fix there.
-- Alexander
On Thu, Oct 4, 2012 at 2:09 PM, Alexander Kostikov
wrote:
>> Having the
>> last page of that output should give us enough context as to where it's
>> faili
Am Mittwoch, 3. Oktober 2012, 16:13:16 schrieb Jeff King:
> On Wed, Oct 03, 2012 at 12:41:38PM -0700, Shawn O. Pearce wrote:
> > > Out of curiosity, how are you thinking about triggering such a new
> > > behavior in a backwards-compatible way? Invoke git-upload-pack2, and
> > > fall back to reconne
On Thu, Oct 04, 2012 at 01:41:40PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > [1] One thing I've been toying is with "external alternates"; dumping
> > your large objects in some realtively slow data store (e.g., a
> > RESTful HTTP service). You could cache and cheaply query
> I'm not sure to follow everything... But looks like:
>
>$ git add -p
>
> or
>
>$ git add -i
>
> should do what you want, no?
>
> You select the hunks to commit, let over the "hacks" and then
>
>$ git commit
Similar but not quite; the idea is that you know that there is some
code (I'
Hi Philip,
> This has the developers having a full copy/history of the integrators
> relevant branches, so that when the pull of the developers branch occurs
> there is a proper link to the integrators history.
True.
>
> There are other ways to create a branch which has all the developers feature
From: "Angelo Borsotti"
Sent: Thursday, October 04, 2012 8:07 AM
Hi Philip and all,
let me explain in full what is the problem that I tried to solve, and
how along the way I stumbled in something that seems to me a git bug
(at least a documentation one).
There is an R&D team developing softwar
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Jeff King writes:
>>
>>> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>>>
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
>>>
From: "Angelo Borsotti"
Sent: Thursday, October 04, 2012 11:09 PM
A reasonable solution. You can also create a sentinel (--root) commit
for
any time that you need to create the source branch, just so it (the
real
source code commit) has a different parent when on source branch to
that on
the b
On 10/04/2012 05:09 PM, Alexander Kostikov wrote:
Full script is uploaded to
https://dl.dropbox.com/u/10828740/rebase.log Here is the last page:
Judging from that log, I'm pretty sure "rebase" is failing at
"format-patch". I was able to reproduce the issue you're having:
"rebase" finished and
On 10/04/2012 05:20 PM, Marco Craveiro wrote:
Similar but not quite; the idea is that you know that there is some
code (I'm just talking about files here, so lets ignore hunks for the
moment) which is normally checked in but for a period of time you want
it ignored. So you don't want it git ignor
Hi Phil,
>
> Another technique could be to simply switch to the sources branch, and then
> use a 'git clean -x' with an updated .gitignore ('reset' the file from the
> source branch)[or use the exclude file] to remove those now ignored
> binaries, before doing the commit.
>
Actually, the first ti
Thanks, Andrew!
I'm looking forward for the patch.
On Thu, Oct 4, 2012 at 3:52 PM, Andrew Wong wrote:
> On 10/04/2012 05:09 PM, Alexander Kostikov wrote:
>>
>> Full script is uploaded to
>> https://dl.dropbox.com/u/10828740/rebase.log Here is the last page:
>
> Judging from that log, I'm pretty
On Thu, Oct 04, 2012 at 11:52:13PM +0200, Sascha Cunz wrote:
> Would it be possible to use this workflow:
>
> - Every client connects per default to v1
>
> - If server is capable of v2, it sends a flag along with the usual response
> (A v1 server will obviously not send that flag)
That is mor
On Thu, Oct 04, 2012 at 12:28:39PM -0700, Junio C Hamano wrote:
> Ben Olive writes:
>
> > My `.git/config` can be corrupted if I try to get a local branch with
> > an extremely long name to track a remote branch.
> >
> > Here is a (contrived) example to reproduce the issue:
>
> Don't do that, t
Op 03-10-12 18:52, Andreas Schwab schreef:
Geoffrey De Smet writes:
Suppose this case:
git clone .../blessedRepo.git
// do changes
git commit -m"bad1"
// do changes
git commit -m"bad2"
git reset --hard HEAD^4 // Why does it let me do this?
Because there is nothing wrong with that.
// I ju
Op 03-10-12 18:40, Phil Hord schreef:
But I feel your pain. I think the solution lies in relegating 'reset'
to the plumbing or the power-user realm of commands since I feel it is
quite overloaded and sometimes dangerous. There was a thread some
months back heading in this direction, but I fail
On 5 October 2012 03:00, Andrew Ardill wrote:
> On 5 October 2012 07:20, Marco Craveiro wrote:
>> ...
>> Similar but not quite; the idea is that you know that there is some
>> code (I'm just talking about files here, so lets ignore hunks for the
>> moment) which is normally checked in but for a p
On Fri, Oct 5, 2012 at 7:05 AM, demerphq wrote:
> On 5 October 2012 03:00, Andrew Ardill wrote:
>> On 5 October 2012 07:20, Marco Craveiro wrote:
>>> ...
>>> Similar but not quite; the idea is that you know that there is some
>>> code (I'm just talking about files here, so lets ignore hunks for
Sitaram Chamarty writes:
>> Git ignore doesn't ignore tracked files.
>
> would 'git update-index --assume-unchanged' work in this case? Didn't
> see it mentioned in any of the replies so far (but I have never used
> it myself)
The assume-unchanged bit is *not* an instruction to tell Git to
igno
On 5 October 2012 12:20, Sitaram Chamarty wrote:
> On Fri, Oct 5, 2012 at 7:05 AM, demerphq wrote:
>> On 5 October 2012 03:00, Andrew Ardill wrote:
>>> On 5 October 2012 07:20, Marco Craveiro wrote:
...
Similar but not quite; the idea is that you know that there is some
code (I'm
Geoffrey De Smet writes:
> Op 03-10-12 18:40, Phil Hord schreef:
>> But I feel your pain. I think the solution lies in relegating 'reset'
>> to the plumbing or the power-user realm of commands since I feel it is
>> quite overloaded and sometimes dangerous. There was a thread some
>> months back
These files are from rsync.git commit
f92f5b166e3019db42bc7fe1aa2f1a9178cd215d, which was the last commit
before rsync turned GPL-3. All files are imported as-is and
no-op. Adaptation is done in a separate patch.
rsync.git -> git.git
lib/wildmatch.[ch] wildmatch.[ch]
wildtest.c
On Thu, Oct 4, 2012 at 12:45 PM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano wrote:
>>> I would recommend against listing any advice.* in the command manual
>>> pages. They are meant to give an advice in cases that are often
>>> confu
Am Donnerstag 04 Oktober 2012, 10:59:36 schrieb Geoffrey De Smet:
> I personally use git reset a lot:
> - Try an experiment
> - Commit a few commits as the experiment progresses
> - figure out that the experiment is a dead end
> - git reset all those local commits
Hmm, what if you do your experim
'format-patch' is failing due to out of memory, and the error not being caught.
So 'rebase' thinks 'am' has completed successfully and continue on with
cleanup. i.e. move_to_original_branch
So the user loses commits from the original head, and have to rely on reflog to
return to the original head.
1 - 100 of 103 matches
Mail list logo
