Hi List,
after experiencing one crash to many, I'm back to Standard Emacs
(instead of Emacsserver/Emacsclient), thus using 'emacs' (instead of
emacsclient) as git core editor triggers reading my huge init file and
is way to slow.
I would like to use Zile (a small Emacs clone) instead, and
When running `git clean`, it will be convenient and safe to show a
confirm dialog and only delete files and directories when confirmed.
The confirm dialog will popup when:
* run `git clean` in interactive sessions,
* not a dry run,
* and not quiet.
There may be existing scripts that call `git
2. git rebase -i master fails unless I've rebased my branch on top of
master. I always wished I could do the equivalent of 'git rebase -i
master..', but I can't. Can we give the A..B syntax a new meaning in
the context of rebase, namely $(git merge-base A B)?
If I understand well, you're
Jiang Xin worldhello@gmail.com writes:
* run `git clean` in interactive sessions,
* not a dry run,
* and not quiet.
Err, does this mean I'll have:
$ git clean
fatal: clean.requireForce defaults to true and neither -n nor -f given;
refusing to clean
$ git clean --force
Are you sure
Hi,
Is the GIT_EDITOR or EDITOR environment variable set? They may be
overriding the core.editor setting.
--
Cheers,
Ray Chuan
On Fri, Apr 26, 2013 at 3:39 PM, Thorsten Jolitz tjol...@gmail.com wrote:
Hi List,
after experiencing one crash to many, I'm back to Standard Emacs
(instead of
Tay Ray Chuan rcta...@gmail.com writes:
Hi,
Is the GIT_EDITOR or EDITOR environment variable set? They may be
overriding the core.editor setting.
Actually, EDITOR is set to Zile, so that should not be the problem:
[tj@hostname ~]$ echo $EDITOR
/usr/bin/zile
[tj@hostname ~]$ echo $GIT_EDITOR
2013/4/26 Matthieu Moy matthieu@grenoble-inp.fr
Jiang Xin worldhello@gmail.com writes:
* run `git clean` in interactive sessions,
* not a dry run,
* and not quiet.
Err, does this mean I'll have:
$ git clean
fatal: clean.requireForce defaults to true and neither -n nor -f
Am 4/26/2013 10:19, schrieb Yann Dirson:
2. git rebase -i master fails unless I've rebased my branch on top of
master. I always wished I could do the equivalent of 'git rebase -i
master..', but I can't. Can we give the A..B syntax a new meaning in
the context of rebase, namely $(git
Jiang Xin worldhello@gmail.com writes:
Maybe we can do like this:
1. Set the default value of 'clean.requireForce' to false.
2. Show a error message and do nothing, if there is not 'clean.requireForce'
setting, but the user called with a '--force' flag.
( like a transition for
Jiang Xin worldhello@gmail.com writes:
I don't know how many programmers had been bitten by runing `git clean -fdx`,
but I bet there were some. I think safety should be put to the 1st place.
It is because clean.requireForce defaults to true, all people trend to run
'git clean' with the
Thorsten Jolitz tjol...@gmail.com writes:
BTW - would 'git config --global core.editor zile' or 'git config
--global core.editor /usr/bin/zile' the right way to set it (both did
not work)? I can start Zile simply with 'zile' on the command line.
What do you mean by did not work? Does the
The shell syntax export X=Y is not understood by all shells.
Split the non portable line into separate lines like this:
X=Y
export X
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
contrib/remote-helpers/test-hg-hg-git.sh | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
The shell syntax export X=Y A=B is not understood by all shells.
Split the non portable line into separate lines like this:
A=B
X=Y
export A X
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
contrib/remote-helpers/test-hg-bidi.sh | 11 ++-
1 file changed, 6 insertions(+), 5
The shell syntax export X=Y is not understood by all shells.
Split the non portable line into separate lines like this:
X=Y
export X
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t9501-gitweb-standalone-http-status.sh | 15 ++-
1 file changed, 10 insertions(+), 5
The shell syntax export X=Y is not understood by all shells.
Split the non portable line into separate lines like this:
X=Y
export X
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t9020-remote-svn.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
The shell syntax export X=Y A=B is not understood by all shells.
Split the non portable line into separate lines like this:
A=B
X=Y
export A X
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t7409-submodule-detached-worktree.sh | 14 ++
1 file changed, 10 insertions(+), 4
On 2013-04-25 22.46, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
Spilt lines like export X=Y into 2 lines:
X=Y
export X
That can be read from the patch text.
If you are going to spend three lines, please describe why it has to
be split; that would help educate
Felipe Contreras wrote:
I am helping my fellow developers by replying to the comments they
make when I send the patches for review. Unfortunately, the only
developer other than you that has made any comment at all, Ramkumar
Ramachandra, did so in a bellicose tone, but I replied to all his
Junio C Hamano venit, vidit, dixit 25.04.2013 19:12:
Junio C Hamano gits...@pobox.com writes:
Michael J Gruber g...@drmicha.warpmail.net writes:
fc407f9 (Add new simplified git-remote-testgit, 2012-11-28) introduced a
test which was meant to skip the test unless the test shell is bash.
2013/4/26 Matthieu Moy matthieu@grenoble-inp.fr:
Jiang Xin worldhello@gmail.com writes:
Maybe we can do like this:
1. Set the default value of 'clean.requireForce' to false.
2. Show a error message and do nothing, if there is not 'clean.requireForce'
setting, but the user called
Ramkumar Ramachandra wrote:
The range version of $(git merge-base A B) B is B ^$(git merge-base A
B), and not B --not $(git merge-base --all A B) [which is equivalent
to B ^A or A..B].
Let me make this easier for you, and everyone else.
In git.git, checkout master and merge 9915605c^2
Ramkumar Ramachandra wrote:
Think of it as a time-truncated version of git log pu: it has
nothing to do with reachability.
Er, scratch that out. I don't like talking in vague terms, and this
feature has nothing to do with git log --since (which is what
time-truncated is).
--
To unsubscribe
Junio C Hamano venit, vidit, dixit 24.04.2013 20:55:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Grepping through the binary, on the other hand, can very well make
sense, like:
$ git grep foo
file.txt: some instance of foo
binary file bar.bin matches
BTW, textconv does not have to
Felipe Contreras wrote:
Any sensible reviewer would be context aware, notice that this
is a contrib patch, and focus on behavioral changes, notice the
mistake I made, and point that *one* of the changes was changing the
behavior, at which point I would agree and reroll either without that
Johannes Sixt wrote:
git rebase -i master..topic
git rebase -i master...topic
We absolutely don't want to go down the inconsistent diff UI route. See [1].
[1]: http://thread.gmane.org/gmane.comp.version-control.git/48
--
To unsubscribe from this list: send the line unsubscribe git
Michael J Gruber g...@drmicha.warpmail.net writes:
BTW, textconv does not have to be slow - just use textconv-cache.
Right, thanks for reminding me about this, I had forgotten its existance ;-).
I'm still looking for a way to at least treat git grep and git show
blob the same way.
I agree
On Thu, Apr 25, 2013 at 4:20 PM, Duy Nguyen pclo...@gmail.com wrote:
On Fri, Apr 26, 2013 at 2:44 AM, Robert Zeh robert.allan@gmail.com
wrote:
Can you just replace lstat/stat with cached_lstat/stat inside
git-compat-util.h and not touch all files at once? I think you may
need to deal
Matthieu Moy matthieu@grenoble-inp.fr writes:
Thorsten Jolitz tjol...@gmail.com writes:
BTW - would 'git config --global core.editor zile' or 'git config
--global core.editor /usr/bin/zile' the right way to set it (both did
not work)? I can start Zile simply with 'zile' on the command
Jiang Xin worldhello@gmail.com writes:
I don't know how many programmers had been bitten by runing `git clean -fdx`,
but I bet there were some. I think safety should be put to the 1st place.
git clean without -n/f errors out, hinting the availablilty of -n
while mentioning -f; that is the
Junio C Hamano gits...@pobox.com writes:
git clean without -n/f errors out, hinting the availablilty of -n
while mentioning -f; that is the safety, isn't it? Once the user
decides to give -f, the user _wants_ to remove cruft, and it is a
hinderance to require any further confirmation.
This
Torsten Bögershausen tbo...@web.de writes:
On 2013-04-25 22.46, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
Spilt lines like export X=Y into 2 lines:
X=Y
export X
That can be read from the patch text.
If you are going to spend three lines, please describe why it
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 25, 2013 at 8:07 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I forgot to mention; these apply on top of the previous 'fixes and cleanups'.
Then I should probably wait for v2 6/9 of that series is rerolled.
There
Thorsten Jolitz tjol...@gmail.com writes:
... I think what I really would like to
have it that, when I use GNU Emacs Magit and enter a git command
,-
| Run git like this: command
`-
that calls an editor (e.g. commit --amend), the
Matthieu Moy matthieu@grenoble-inp.fr writes:
The nice thing with the confirmation dialog is that it shows the list
before asking (and unlike 'rm -i', it asks only once).
I wouldn't object to having clean -i, which automatically defeats
the requireforce option.
As to a huge single list
Pierre-François CLEMENT lik...@gmail.com writes:
As you can see, the --cumulative lines seem to be duplicated, though
the computed stats aren't exactly the same... It appears when you
combine the --cumulative option with either --stat, --numstat or
--shortstat (but not --dirstat) ...
Thanks
Since I reboot fairly regularly to test new kernels, I don't *always*
have the kernel source tree in my caches, so I still care about some
cold-cache performance. And git grep tends to be the most noticeable
one.
Now, I have a SSD, and even the cold-cache case takes just five
seconds or so, but
Johannes Sixt j.s...@viscovery.net writes:
Allow alternative spelling of
git rebase -i master topic
like this:
git rebase -i master..topic
(as always, the default for topic is HEAD).
I actually made this typo a few times in the past.
In a single-strand-of-pearls history, what
Commit d24fbca (Remove Git's support for smoke testing - 2011-12-23)
removed the smoke test support from the test suite but it was re-added
by commit 342e9ef (Introduce a performance testing framework -
2012-02-17). This appears to be the result of a mis-merge, since
re-adding the smoke testing
Junio C Hamano gits...@pobox.com writes:
Thorsten Jolitz tjol...@gmail.com writes:
... I think what I really would like to
have it that, when I use GNU Emacs Magit and enter a git command
,-
| Run git like this: command
`-
that
Michael J Gruber g...@drmicha.warpmail.net writes:
It is a separate issue to port git-remote-testgit to POSIX (J6t
already has a two part draft), move it to git-remote-testgit.sh, and
get its shebang line preprocessed like all other shell scripts. I
think it is worth doing.
Takers?
By
On Fri, Apr 26, 2013 at 4:32 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
I am helping my fellow developers by replying to the comments they
make when I send the patches for review. Unfortunately, the only
developer other than you that has made any comment at all,
Linus Torvalds torva...@linux-foundation.org writes:
Wouldn't it be lovely if it was slightly smarter (something more akin
to the index preloading that takes number of files into account) or at
least allowed people to set the parallelism explicitly with a command
line switch?
Yeah, a
On Fri, Apr 26, 2013 at 7:19 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
Any sensible reviewer would be context aware, notice that this
is a contrib patch, and focus on behavioral changes, notice the
mistake I made, and point that *one* of the changes was
Felipe Contreras wrote:
What is your objective, do you want to help this project move forward or not?
Forward, please.
I want a solution to this persistent problem of conflict though. And
I presented one in my previous email:
Here's my solution to the problem: maintain your project outside
On Fri, Apr 26, 2013 at 11:47 AM, Junio C Hamano gits...@pobox.com wrote:
The real issue may be that we do not have a good estimate of how
many paths are involved in the request before starting these
threads, though.
Yes. Also, I'm not sure if the 15% possible improvement on my SSD case
is
When TEST_OUTPUT_DIRECTORY is set, the test results will be generated in
$TEST_OUTPUT_DIRECTORY/test-results, which may not be the same as
test-results in t/Makefile. This causes the aggregate-results target
to fail as it finds no count files.
Fix this by introducing TEST_RESULTS_DIRECTORY and
Most test results go in $TEST_OUTPUT_DIRECTORY, but the output files for
tests run with --tee or --valgrind just use bare test-results.
Changes these so that they do respect $TEST_OUTPUT_DIRECTORY.
As a result of this, the valgrind/analyze.sh script may no longer
inspect the correct files so it
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
The nice thing with the confirmation dialog is that it shows the list
before asking (and unlike 'rm -i', it asks only once).
I wouldn't object to having clean -i, which automatically defeats
the
On Fri, Apr 26, 2013 at 4:32 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
Junio C Hamano wrote:
I do
not agree with Ram at all when he says that developers are more
important than users, and I agree with you that the project exists
for users, and not for
Linus Torvalds torva...@linux-foundation.org writes:
Yes. Also, I'm not sure if the 15% possible improvement on my SSD case
is even worth it for something that in the end isn't necessarily the
common case.
Cold cache being uncommon case would be forever true but more and
more people are on
On 25/04/2013 21:19, Junio C Hamano wrote:
How many decorations are we talking about here? One for each merge
commit in the entire history? Do we have a cue that can tell us when
we are really done with a commit that lets us discard the associated
data as we go on digging, keeping the size of
[completely off-topic; don't worry, we're just having a friendly chat]
Felipe Contreras wrote:
If you are not prepared to defend your review, so are others, why to
you blame that on me? If you were right, you would be shown to be
right. Period.
Felipe, there are some things that are worth
Historically TREESAME was set on a commit if it was TREESAME to _any_ of
its parents. This is not optimal, as such a merge could still be worth
showing, particularly if it is an odd -s ours merge that (possibly
accidentally) dropped a change. And the problem is further compounded by
the fact that
On Fri, Apr 26, 2013 at 1:53 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
What is your objective, do you want to help this project move forward or not?
Forward, please.
I want a solution to this persistent problem of conflict though. And
I presented one in my
Felipe Contreras wrote:
If you don't understand the reasoning and history behind remote-bzr,
you might be doing a disservice to everyone by commenting at all.
Felipe, I'm trying to help. If you think my review lacked context,
you can write me a paragraph/ link me to an email and I will read
In the event of an odd merge, we may find ourselves TREESAME to
apparently redundant parents. Prevent simplify_merges() from removing
every TREESAME parent - in the event of such a merge it's useful to see
where we came actually from came.
Signed-off-by: Kevin Bracey ke...@bracey.fi
---
On Fri, Apr 26, 2013 at 12:49 PM, Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j.s...@viscovery.net writes:
Allow alternative spelling of
git rebase -i master topic
like this:
git rebase -i master..topic
(as always, the default for topic is HEAD).
I actually made this
Reimplement commit 4b7f53da on top of the new simplify-merges
infrastructure, tightening the condition to only consider root parents;
the original version incorrectly dropped parents that were TREESAME to
anything.
Original log message follows.
The merge simplification rule stated in 6546b59
Felipe Contreras wrote:
We all benefit from these patches being reviewed in the git mailing
list, nobody has claimed otherwise. You are making the error of
assuming that your review was actionable, that I should have done
something, fix the commit message I suppose, but I don't think that's
Ramkumar Ramachandra wrote:
Diversity is certainly healthy, and I it would be nice to have you in
the community. We just have to find a way to keep the conflict down.
After all, what are we asking for? Better commit messages. Why are
you making such a big deal out of it? You want diversity
On Fri, Apr 26, 2013 at 2:30 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
[completely off-topic; don't worry, we're just having a friendly chat]
Felipe Contreras wrote:
If you are not prepared to defend your review, so are others, why to
you blame that on me? If you were right, you
Felipe Contreras wrote:
A fine way to start is to not rattle away in trivial inconsequential patches.
I have something from Linus (TM) this time :)
https://lkml.org/lkml/2004/12/20/255
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Felipe Contreras wrote:
The importance of users changes all the time. The 15 year old kid in
Sao Paulo might not be important today, but he might be the single
most important contributor ten years from now. Hell, he might even
replace Junio as the maintainer.
Yes, they do. Did I say that
On Fri, Apr 26, 2013 at 2:56 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
We all benefit from these patches being reviewed in the git mailing
list, nobody has claimed otherwise. You are making the error of
assuming that your review was actionable, that I should
Felipe Contreras wrote:
If you are so keen in receiving feedback from your fellow developers,
you should eventually send an email summarizing the issues and the
proposal for everyone to understand.
Thanks. I'll do that in the morning.
Reason is not a tool for appreciating art, reason is a
On Fri, Apr 26, 2013 at 3:03 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
A fine way to start is to not rattle away in trivial inconsequential patches.
I have something from Linus (TM) this time :)
https://lkml.org/lkml/2004/12/20/255
I happen to agree with
On Fri, Apr 26, 2013 at 12:19 PM, Junio C Hamano gits...@pobox.com wrote:
OK, you have to recompile at least once for experiment, so perhaps
building the test binary with this patch may help.
So here's my experiment on my machine with this patch and the kernel
tree. First I did the warm-cache
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
Maybe the warning should happen after add_file_to_index() has run,
letting git compare the old and new index entries for that path?
Yeah, new and deleted cases we do not have to worry about, so a
no-op
On Fri, Apr 26, 2013 at 3:28 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Reason is not a tool for appreciating art, reason is a tool for
discovering truth, and if when arguing you are not interested in what
is actually true, I'm not interested in arguing with you.
There is no great
On Fri, Apr 26, 2013 at 3:17 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
The importance of users changes all the time. The 15 year old kid in
Sao Paulo might not be important today, but he might be the single
most important contributor ten years from now. Hell,
Felipe Contreras felipe.contre...@gmail.com writes:
I don't know what 'git rebase master' does, but I would expect 'git
rebase --onto=master' to do the same thing. Then, if 'git rebase
--onto=next master..topic' makes sense, so should 'git rebase next
master..topic'.
Moreover, it often
Updated the commit messages, so we say Bazaar instead of Mercurial, and stuff.
Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg.
Felipe Contreras (9):
remote-helpers: trivial cleanups
remote-hg: remove extra check
remote-bzr: fix bad state issue
remote-bzr: add
No functional changes. Typos, unused variables, redundant operations,
and white-spaces.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 7 ---
contrib/remote-helpers/git-remote-hg | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
Not needed since we use xrange ourselves.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4
1 file changed, 4 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index cfa96c1..80b3606
Carried from remote-hg.
The problem reportedly happened after doing a push that fails, the abort
causes the state of remote-hg to go bad, this happens because
remote-hg's marks are not stored, but 'git fast-export' marks are.
Ensure that the marks are _always_ stored.
Signed-off-by: Felipe
Just like in remote-hg.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index
To be in sync with remote-bzr.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index
Otherwise we get notification, progress bars, and what not.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
Bazaar might convert the URL to something more appropriate, like an
absolute path. Lets store that instead of the original URL, which won't
work from a different working directory if it's relative.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Not just randomly synchronize the revisions with no checks at all. This
is the way bazaar's UI does it.
Also, add a non-ff check.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
It's added by fast-export, the user didn't type it.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index
On Fri, Apr 26, 2013 at 11:51 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 25, 2013 at 8:07 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I forgot to mention; these apply on top of the previous 'fixes and cleanups'.
Junio C Hamano wrote:
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -495,6 +495,8 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
refresh(verbose, pathspec);
goto finish;
}
+ if (implicit_dot !prefix)
+
On Thu, Apr 25, 2013 at 12:56 AM, Johannes Sixt j.s...@viscovery.net wrote:
From: Johannes Sixt j...@kdbg.org
Bash on Windows does not implement process substitution.
Nevermind, reporting all the refs creates a lot of irrelevant output,
this version is fine.
Acknowledged-by: Felipe Contreras
Felipe Contreras felipe.contre...@gmail.com writes:
Updated the commit messages, so we say Bazaar instead of Mercurial, and stuff.
Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg.
Thanks. Will queue on 'pu' without looking.
--
To unsubscribe from this list: send the
On Fri, Apr 26, 2013 at 5:10 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Good, so I'll keep sending the patches, because our users benefit from
the review.
Just for the record, a patch sent to the list which nobody bothered
to read does
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
Updated the commit messages, so we say Bazaar instead of Mercurial, and
stuff.
Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg.
Thanks. Will queue on 'pu' without
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 25, 2013 at 12:56 AM, Johannes Sixt j.s...@viscovery.net wrote:
From: Johannes Sixt j...@kdbg.org
Bash on Windows does not implement process substitution.
Nevermind, reporting all the refs creates a lot of irrelevant output,
On Fri, Apr 26, 2013 at 5:23 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
Updated the commit messages, so we say Bazaar instead of Mercurial, and
stuff.
Here's a bunch of cleanups mostly to
On Fri, Apr 26, 2013 at 5:25 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 25, 2013 at 12:56 AM, Johannes Sixt j.s...@viscovery.net wrote:
From: Johannes Sixt j...@kdbg.org
Bash on Windows does not implement process substitution.
Hi,
On Thu, Apr 25, 2013 at 2:59 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This script find people that might be interested in a patch, by going
back through the history for each single hunk modified, and finding
people that reviewed, acknowledge, signed, or authored the code the
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 25, 2013 at 2:59 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This script find people that might be interested in a patch, by going
back through the history for each single hunk modified, and finding
people that
On Fri, Apr 26, 2013 at 6:01 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 25, 2013 at 2:59 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This script find people that might be interested in a patch, by going
back through
Felipe Contreras felipe.contre...@gmail.com writes:
No, it wouldn't, but I don't think there's any way to do \\ or \b in globs.
This should do in the meantime, but it further needs:
- J6t's sign off for the follow-up part to remove remaining
bash-isms to complete this patch (the last part
On Thu, Apr 25, 2013 at 8:08 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This way all the remotes can share the same git objects, and the same
marks. The information we want to store per remote is very small.
The code transparently converts from one organization of marks, to the
Felipe Contreras felipe.contre...@gmail.com writes:
And in case anybody is thinking that remote-bzr is really a too fast
moving target; even if this managed to land in 'master', it's likely
that people were not able to push at all, and in fact, many were not
even able to clone in 1.8.2. So,
The latest maintenance release Git v1.8.2.2 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
47a86a0a4f92998f21ada77be146676ecfd2e4af git-1.8.2.2.tar.gz
A release candidate preview Git v1.8.3-rc0 is now available for
testing at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
f0b0b415f0c693865895c1918859b12c4a7d5b17 git-1.8.3.rc0.tar.gz
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The release candidate preview 1.8.3-rc0 has been tagged. I'd like to
see people focus on catching and fixing last minute regressions and
On Fri, Apr 26, 2013 at 7:17 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
And in case anybody is thinking that remote-bzr is really a too fast
moving target; even if this managed to land in 'master', it's likely
that people were not able to
1 - 100 of 108 matches
Mail list logo
