I started writing this script in a repo I have called misc-scripts
where I just keep one off projects and the like (notes, throw away
scripts, etc). Well, my boss asked me to create a repo for one of
these scripts and I'd like to keep the commit history.
Ok, so:
% find -type f ! -iname webban.pl
On 08/07/2013 01:31 AM, Junio C Hamano wrote:
The parseopt parsing for OPT__FORCE() is implemented in terms of
OPT_BOOLEAN() and users of it can take advantage of the counting
up behaviour to implement increasing levels of forcefulness by
differentiating git cmd -f and git cmd -f -f.
Duy Nguyen pclo...@gmail.com writes:
A little bit more..
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com
wrote:
+static void ce_queue_push(struct cache_entry **head,
+struct cache_entry **tail,
+struct
Christian Couder chrisc...@tuxfamily.org writes:
Users replacing an object with one of a different type were not
prevented to do so, even if it was obvious, and stated in the doc,
that bad things would result from doing that.
To avoid mistakes, it is better to just forbid that though.
The
Matthieu Moy matthieu@imag.fr writes:
At least GNU echo interprets backslashes in its arguments.
This triggered at least one bug: the error message of rebase -i was
turning \t in commit messages into actual tabulations. There may be
others.
Using printf '%s\n' instead avoids this bad
Ralf Thielow ralf.thie...@gmail.com writes:
The changes look good to me. The following is purely about the original
English messages.
#: builtin/commit.c:62
-#, fuzzy
msgid
The previous cherry-pick is now empty, possibly due to conflict
resolution.\n
If you wish to commit it
On Wed, Aug 07, 2013 at 11:17:08AM +0200, Thomas Rast wrote:
This results from Peff's c17592a (commit: tweak empty cherry pick advice
for sequencer, 2013-07-26):
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..39717d5 100644
--- a/builtin/commit.c
+++
Thomas Rast tr...@inf.ethz.ch writes:
+grep -v error
Umm, doesn't that only test that _some_ line in the error does not
contain a tab?
Indeed. It does work as the error message is just a one-liner, but let's
be robust anyway.
Whereas you need to test that _no_ line contains
Some implementations of 'echo' (e.g. dash's built-in) interpret
backslash sequences in their arguments.
This triggered at least one bug: the error message of rebase -i was
turning \t in commit messages into actual tabulations. There may be
others.
Using printf '%s\n' instead avoids this bad
Matthieu Moy matthieu@grenoble-inp.fr writes:
Thomas Rast tr...@inf.ethz.ch writes:
+ grep -v error
Umm, doesn't that only test that _some_ line in the error does not
contain a tab?
Indeed. It does work as the error message is just a one-liner, but let's
be robust anyway.
Am 8/7/2013 8:24, schrieb shawn wilson: ... create a repo for one of
these scripts and I'd like to keep the commit history.
Ok, so:
% find -type f ! -iname webban.pl | while read f; do git
filter-branch -f --index-filter git rm --cached --ignore-unmatch $f
HEAD ; done
Which basically did
On 07/29/2013 08:02 PM, Daniele Segato wrote:
On 07/26/2013 09:36 PM, Jonathan Nieder wrote:
Eventually the description section should probably be tweaked to start
by explaining what the command is actually for. ;-)
Elaborating from this suggestion you gave me I tried to
rewrite/rearrange the
Hello.
I find 2 bug about Japanese' Documentation .
There are Documentation - Book 's url. ( Please see the details below).
I want to bug-fix about this misspell.
Do you have Documentation (about Japanese language) on the GitHub?
(1)
# I am sorry. I forget title and signiture.
-
Hello.
I find 2 bug about Japanese' Documentation .
There are Documentation - Book 's url. ( Please see the details below).
I want to bug-fix about this misspell.
Do you have Documentation (about Japanese language) on the GitHub?
---
pack-write.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/pack-write.c b/pack-write.c
index e6aa7e3..b728ea2 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -344,6 +344,11 @@ struct sha1file *create_tmp_packfile(char **pack_tmp_name)
return sha1fd(fd, *pack_tmp_name);
}
---
builtin/pack-objects.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 0bd8f3b..0fe01fc 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2795,6 +2795,9 @@ int cmd_repack(int argc, const char **argv, const char
---
builtin/pack-objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 1742ea1..0bd8f3b 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2585,7 +2585,7 @@ int cmd_pack_objects(int argc, const char
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
pack-objects learns a few more options to take over what's been done
by git-repack.sh. cmd_repack() becomes a wrapper around
cmd_pack_objects().
---
Makefile | 2 +-
builtin.h | 1 +
Hi Duy,
I applied your patch on the current master and added 3 patches,
so git compiles and the testsuite works without additional breakages.
The functionality is obviously not yet completed as the backup_file
function is still empty. What do you intend that function will do?
Stefan
Nguyễn
[ It's cool you're working on this, I'd really like a git-repack in C.
That would fix this
http://thread.gmane.org/gmane.comp.version-control.git/226458 ]
Stefan Beller stefanbel...@googlemail.com writes:
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
pack-objects learns a few more options
Stefan Beller stefanbel...@googlemail.com writes:
On 08/07/2013 01:31 AM, Junio C Hamano wrote:
The parseopt parsing for OPT__FORCE() is implemented in terms of
OPT_BOOLEAN() and users of it can take advantage of the counting
up behaviour to implement increasing levels of forcefulness by
If the current branch has an upstream branch, and there are differences
between the current branch and its upstream, some commands (such as
git status, git status -bs, and git checkout) will report their
relationship. E.g.
$ git status
# On branch master
# Your branch is ahead of
Matthieu Moy matthieu@grenoble-inp.fr writes:
[ It's cool you're working on this, I'd really like a git-repack in C.
That would fix this
http://thread.gmane.org/gmane.comp.version-control.git/226458 ]
Stefan Beller stefanbel...@googlemail.com writes:
From: Nguyễn Thái Ngọc Duy
Jiang Xin worldhello@gmail.com writes:
With this patch, git status will report relationship between current
branch and its upstream counterpart even if there is no difference.
$ git status
# On branch master
# Your branch is identical to its tracking branch: 'origin/master'.
Problem:
git log --follow filename is not working for files after a big move.
Scenario:
Just performed a git subtree add where big projects were moved into
another repository, and I'm not able to view history for a single
file.
Sample output:
Output after subtree add (no output)
git log
Hi,
This is the difference between whatchanged and log:
diff --git a/whatchanged b/log
index fa1b223..004d9aa 100644
--- a/tmp/whatchanged
+++ b/tmp/log
@@ -1,4 +1,4 @@
-int cmd_whatchanged(int argc, const char **argv, const char *prefix)
+int cmd_log(int argc, const char **argv, const char
2013/8/7 Matthieu Moy matthieu@grenoble-inp.fr:
Jiang Xin worldhello@gmail.com writes:
With this patch, git status will report relationship between current
branch and its upstream counterpart even if there is no difference.
$ git status
# On branch master
# Your branch
On 08/07/2013 05:48 PM, Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
seems overkill to me: why don't you just let cmd_repack call
update_server_info(0)?
My feeling exactly. I would rather see a patch that does not touch
pack-objects at all, and use run_command()
Am 06.08.2013 23:11, schrieb Junio C Hamano:
Thanks, will replace the top two commits and queue. Looks like we
are getting ready for 'next'?
I hope so, I'm not aware of any open issues.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On 08/07/2013 06:00 PM, Ramkumar Ramachandra wrote:
Hi,
This is the difference between whatchanged and log:
diff --git a/whatchanged b/log
index fa1b223..004d9aa 100644
--- a/tmp/whatchanged
+++ b/tmp/log
@@ -1,4 +1,4 @@
-int cmd_whatchanged(int argc, const char **argv, const char
Stefan Beller stefanbel...@googlemail.com writes:
I'd deprecate it first for a year or such and remove it then.
In the meantime we could implement already remove the code
and change it to:
+ int cmd_whatchanged(int argc, const char **argv, const char *prefix)
+ {
+ return cmd_log(argc,
On Aug 7, 2013, at 09:00, Ramkumar Ramachandra wrote:
Hi,
This is the difference between whatchanged and log:
diff --git a/whatchanged b/log
index fa1b223..004d9aa 100644
--- a/tmp/whatchanged
+++ b/tmp/log
@@ -1,4 +1,4 @@
-int cmd_whatchanged(int argc, const char **argv, const char *prefix)
On Tue, Aug 06, 2013 at 02:11:56PM -0700, Junio C Hamano wrote:
Thanks, will replace the top two commits and queue. Looks like we
are getting ready for 'next'?
I'm a bit curious about if we should move towards a reentrent libgit
(which would for example make multithreading easier) or not.
If
On Wed, Aug 07, 2013 at 11:01:57AM -0700, Kyle J. McKay wrote:
On Aug 7, 2013, at 09:00, Ramkumar Ramachandra wrote:
Hi,
This is the difference between whatchanged and log:
diff --git a/whatchanged b/log
index fa1b223..004d9aa 100644
--- a/tmp/whatchanged
+++ b/tmp/log
@@ -1,4
On Aug 7, 2013, at 11:31, John Keeping wrote:
On Wed, Aug 07, 2013 at 11:01:57AM -0700, Kyle J. McKay wrote:
On Aug 7, 2013, at 09:00, Ramkumar Ramachandra wrote:
Hi,
This is the difference between whatchanged and log:
diff --git a/whatchanged b/log
index fa1b223..004d9aa 100644
---
On 08/07/2013 07:50 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
I'd deprecate it first for a year or such and remove it then.
In the meantime we could implement already remove the code
and change it to:
+ int cmd_whatchanged(int argc, const char **argv,
Hello, I need some guide that can explain me the following:
I wish to know the correct rule to make work cloning over http with my
configuration, without taking all the web server to server only as
github
I setup gitweb to it can show in a directory
by example, localhost/gitweb or
This is an attempt to reproduce a problem reported for a third-party
custom connect remote helper. The conjecture is that sometimes
git fetch wants to make two connections (one for the primary
transfer with 'follow-tags' option set, and then after noticing that
some tags are not packed because
git fetch sometimes needs to make a real request to the transport
after a single fetch_refs request, in order to follow tags that
the other end should have sent as part of the primary transfer with
follow-tags request.
However, a transport that defines connect has a gross hack that
destroys its
Usually the upload-pack process running on the other side will give
us all the reachable tags we need during the primary object transfer
in do_fetch(). If that does not happen (e.g. the other side may be
running a third-party implementation of upload-pack), we will run
another fetch to pick up
A Git-aware connect transport allows the transport_take_over to
redirect generic transport requests like fetch(), push_refs() and
get_refs_list() to the native Git transport handling methods. The
take-over process replaces transport-data with a fake data that
these method implementations
Make a helper function prepare_transport() that returns a transport
to talk to a given remote.
The set_option() helper that used to always affect the file-scope
global gtransport now takes a transport as its parameter.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/fetch.c | 46
Although many functions in this file take a struct transport as a
parameter, fetch_one() assigns to the global singleton instance
which is a file-scope static, in order to allow a parameterless
signal handler unlock_pack() to access it.
Rename the variable to gtransport to make sure these uses
Matthijs Kooijman matth...@stdin.nl writes:
In your discussion (including the comment), you talk about shallow
root (I think that is the same as what we call shallow boundary),
I think so, yes. I mean to refer to the commits referenced in
.git/shallow, that have their parents hidden.
Could
On Thu, Aug 8, 2013 at 8:01 AM, Junio C Hamano gits...@pobox.com wrote:
Matthijs Kooijman matth...@stdin.nl writes:
In your discussion (including the comment), you talk about shallow
root (I think that is the same as what we call shallow boundary),
I think so, yes. I mean to refer to the
On Wed, Jul 17, 2013 at 3:11 PM, Thomas Gummerer t.gumme...@gmail.com wrote:
Duy Nguyen pclo...@gmail.com writes:
[..]
+static int read_entries(struct index_state *istate, struct directory_entry
**de,
+ unsigned int *entry_offset, void **mmap,
+
On Wed, Aug 7, 2013 at 3:23 PM, Thomas Gummerer t.gumme...@gmail.com wrote:
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com
wrote:
+static void ce_queue_push(struct cache_entry **head,
+struct cache_entry **tail,
+
On Wed, Aug 7, 2013 at 7:10 AM, Martin Fick mf...@codeaurora.org wrote:
I wonder if a simpler approach may be nearly efficient as
this one: keep the largest pack out, repack the rest at
fetch/push time so there are at most 2 packs at a time.
Or we we could do the repack at 'gc --auto' time,
On Wed, Aug 7, 2013 at 10:48 PM, Junio C Hamano gits...@pobox.com wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
[ It's cool you're working on this, I'd really like a git-repack in C.
That would fix this
http://thread.gmane.org/gmane.comp.version-control.git/226458 ]
Stefan
On Wed, Aug 7, 2013 at 9:00 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
---
pack-write.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/pack-write.c b/pack-write.c
index e6aa7e3..b728ea2 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -344,6 +344,11 @@ struct sha1file
Junio C Hamano wrote:
The only thing it does is to scratch an irrelevant itch by people
who peek the codebase and find an old command whose existence does
not even hurt them. They may have too much time on their hand, but
that is not an excuse to waste other people's time by adding extra
On Fri, Jul 12, 2013 at 5:01 AM, Matthijs Kooijman matth...@stdin.nl wrote:
Hi folks,
while playing with shallow fetches, I've found that in some
circumstances running git fetch with --depth can return too many objects
(in particular, _all_ the objects for the requested revisions are
If the current branch has an upstream branch, and there are changes
between the current branch and its upstream, some commands (such as
git status, git status -bs, and git checkout) will report their
relationship. E.g.
$ git status
# On branch master
# Your branch is ahead of
53 matches
Mail list logo