On Tue, Nov 26, 2013 at 8:50 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
Some buffers created with PATH_MAX length are not checked when being
written, and can overflow if PATH_MAX is not big enough to hold the
path.
Perhaps it is time to update all
Hi!
Let's say I have two identical branches: master and topic. In master I
remove some code, i.e. function bar(). In topic I do the same (commit)
and after some time I realize I need bar() and revert previous commit
with removal.
So I end with master with no bar() and topic with bar() in its
Hi,
my Ubuntu saucy version of gitk is 1.8.3.2-1 I believe.
I want to report what I believe is a bug. I have been using gitk for 3
years, and I use it to verify what I am doing in the shell.
In the version I use now, the behavior has changed.
When I do
mkdir temp
cd temp
git init
touch foo
git
Hi,
there are development workflows where a feature or fix is
by definition implemented in the dev branch and perhaps picked
into a stable/rc branch.
A question often being asked in such a workflow is Is this fix in this
stable branch?. Usually I would call git branch -r --contains $commit
to
I encountered a directory/file conflict when running `git fetch --prune
origin`. I figured passing --prune would automatically fix DF conflicts. After
looking in the code I found that prune is called after fetching. It seemed to
be intentional according historical commits. I made this patch to
When a DF conflict occurs during a fetch, --prune should be able to fix
it. When fetching with --prune, the fetching process happens before
pruning causing the DF conflict to persist and report an error. This
patch prunes before fetching, thus correcting DF conflicts during a
fetch.
On Fri, Nov 29, 2013 at 06:26:25PM +0400, Evgeniy Ivanov wrote:
Hi!
Let's say I have two identical branches: master and topic. In master I
remove some code, i.e. function bar(). In topic I do the same (commit)
and after some time I realize I need bar() and revert previous commit
with
Tom Miller jacker...@gmail.com writes:
When a DF conflict occurs during a fetch, --prune should be able to fix
it. When fetching with --prune, the fetching process happens before
pruning causing the DF conflict to persist and report an error. This
patch prunes before fetching, thus correcting
When trying to pop/apply a stash specified with an argument containing
spaces the user will see an error:
$ git stash pop 'stash@{two hours ago}'
Too many revisions specified: stash@{two hours ago}
This happens because word splitting is used to count non-option
arguments. Instead shift
Jonathan Nieder jrnie...@gmail.com writes:
Thomas Rast wrote:
+ *
+ * - void clear_indegree(struct indegree *);
+ *
+ * Free the slab's data structures.
Tense shift (previous descriptions were in the present tense, while
this one is in the imperative).
More importantly, this doesn't
Øystein Walle oys...@gmail.com writes:
When trying to pop/apply a stash specified with an argument containing
spaces the user will see an error:
$ git stash pop 'stash@{two hours ago}'
Too many revisions specified: stash@{two hours ago}
This happens because word splitting is used
When trying to pop/apply a stash specified with an argument containing
spaces git-stash will throw an error:
$ git stash pop 'stash@{two hours ago}'
Too many revisions specified: stash@{two hours ago}
This happens because word splitting is used to count non-option
arguments. Make use of
TLDR: nitpicks. Thanks for a very nice read.
I do think it's worth fixing the syntax pedantry at the end so that we
can keep supporting arcane compilers, but otherwise, meh.
+static int open_pack_bitmap_1(struct packed_git *packfile)
This goes somewhat against the naming convention (if you
Thanks for looking into this!
Øystein Walle oys...@gmail.com writes:
- REV=$(git rev-parse --quiet --symbolic --verify $1 2/dev/null) || {
+ REV=$(git rev-parse --quiet --symbolic --verify $1 2/dev/null) || {
reference=$1
It's somewhat ironic that the one place where
On Wed, Nov 27, 2013 at 11:43:44AM -0800, Junio C Hamano wrote:
Nick Townsend nick.towns...@mac.com writes:
* The .gitmodules file can be dirty (easy to flag, but should we
allow archive to proceed?)
As we are discussing archive, which takes a tree object from the
top-level project that
On Mon, Nov 25, 2013 at 12:53:45PM -0800, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
What I think needs fixing here first is that the ignore setting should not
apply to any diffs between HEAD and index. IMO, it should only apply
to the diff between worktree and index.
If the value of ignore for submodules is set to all we would not show
whats actually committed during status or diff. This can result in the
user committing unexpected submodule references. Lets be nicer and always
show whats in the index.
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
---
On Thu,
Hi,
I am trying to git-svn clone
https://svn.calendarserver.org/repository/calendarserver/CalendarServer/
and I cannot say I am much succesful. Every couple of hundred of commits
I get this:
RA layer request failed: REPORT of
'/repository/calendarserver/!svn/vcc/default': could not connect to
On 2013-11-29, 15:53 GMT, Thomas Ferris Nicolaisen wrote:
https://github.com/schacon/ticgit - with all its forks and
descendants. Not sure which ones are the most active.
Probably the most active is
https://github.com/glogiotatidis/gitissius/, but generally whole
landscape of the distributed
On Nov 29, 2013, at 06:26, Evgeniy Ivanov wrote:
Let's say I have two identical branches: master and topic. In master I
remove some code, i.e. function bar(). In topic I do the same (commit)
and after some time I realize I need bar() and revert previous commit
with removal.
So I end with master
Bug 6530 [1] causes git show v0.99.6~1 to fail with error your
vsnprintf is broken. The workaround avoids that, but it corrupts
system error messages in non-C locales.
The bug has been fixed since 2.17. If git is built with glibc, it can
know running libc version with gnu_get_libc_version() and
21 matches
Mail list logo
