On 22/02/14 18:18, Robert Dailey wrote:
> So it seems that the pager doesn't work by default when running `git
> log` from Cygwin like it does in msysgit for Windows.
>
> I know I can pipe to `less` but that requires the additional typing
> obviously. Does anyone know how I can get the pager to wo
From: Ryan Schmitt
This makes git-rm more consistent with git-diff, which also accepts
--staged as a synonym of --cached.
Signed-off-by: Ryan Schmitt
---
Documentation/git-rm.txt | 2 +-
builtin/rm.c | 1 +
t/t3600-rm.sh| 6 ++
3 files changed, 8 insertions(+), 1 de
So it seems that the pager doesn't work by default when running `git
log` from Cygwin like it does in msysgit for Windows.
I know I can pipe to `less` but that requires the additional typing
obviously. Does anyone know how I can get the pager to work in Cygwin
for git log, reflog, and other comman
--sort=refname:version (or --sort=refname:v for short) sorts tags as
if they are versions. --sort=-refname reverses the order (with or
without ":version"). This syntax is chosen to make it compatible with
future extension in "for-each-ref --sort"
GNU extension strverscmp is used so this is Linux o
Signed-off-by: Nguyễn Thái Ngọc Duy
---
definitely better than raw numbers but not really important
builtin/index-pack.c | 11 ++-
diff.c | 35 +--
diff.h | 2 ++
3 files changed, 37 insertions(+), 11 deletions(-)
diff --git
On Mon, Feb 17, 2014 at 07:15:32PM +0700, Nguyễn Thái Ngọc Duy wrote:
> @@ -777,6 +778,8 @@ static int prepare_to_commit(const char *index_file,
> const char *prefix,
> _("Please enter the commit message for your
> changes."
> " Lines
On 21.02.2014, at 19:04, Junio C Hamano wrote:
> Here is a description I wrote for a tentative commit to queue on
> 'pu' after seeing your response:
>
>transport-helper.c: do not overwrite forced bit
I'd change "forced bit" to "forced_update bit"
>
>It does not necessarily mean the u
On Wed, Feb 19, 2014 at 3:59 AM, Junio C Hamano wrote:
> I didn't know --agressive was so aggressive myself, as I personally
> never use it. "git repack -a -d -f --depth=32 window=4000" is what I
> often use, but I suspect most people would not be patient enough for
> that 4k window.
>
> Let's do
Hi folks,
Would there be interest in adding back the sample hooks that were
removed in [8d714b11df][1]. I think that they are helpful if only as a
quick reference showing what hooks are possible. (As well spelling
receive incorrectly is a source of confusion (I think), but that's not
a good argume
Junio C Hamano writes:
> Thomas Gummerer writes:
>
>> diff --git a/Documentation/git.txt b/Documentation/git.txt
>> index aec3726..bc9eeea 100644
>> --- a/Documentation/git.txt
>> +++ b/Documentation/git.txt
>> @@ -712,6 +712,11 @@ Git so take care if using Cogito etc.
>> index file. If not
Tay Ray Chuan writes:
> In particular, show that --short and --porcelain, while implying
> --dry-run, do not return the same exit code as --dry-run. This is due to
> the wt_status.commitable flag being set only when a long status is
> requested.
I am not sure if --short/--porcelain should even b
In particular, show that --short and --porcelain, while implying
--dry-run, do not return the same exit code as --dry-run. This is due to
the wt_status.commitable flag being set only when a long status is
requested.
No fix is provided here; with [1], it should be trivial to fix though -
just a mat
One would expect 'git commit --verbose --no-status' to give a commit
message with a diff of the commit, sans the output of git-status.
However, this does not work currently; the commit message body is
entirely empty (diff is absent as well). This is because internally the
status machinery is used t
One would expect 'git commit --verbose --no-status' to give a commit
message with a diff of the commit, sans the output of git-status.
However, this does not work currently; the commit message body is
entirely empty (diff is absent as well). This patch series attempts to
make this work, as one woul
At first glance, wt_status_print_updated() appears to be doing a bunch
of printing (as its name implies), and it may not be immediately obvious
that it also sets the vital wt_status.commitable flag. Extract this out
into a separate function; it is hoped that the improved clarity to
future Git contr
Cc: Jeff King
In f3f47a1 (status: add --long output format option), STATUS_FORMAT_NONE
was introduced, meaning "the user did not specify anything". Rename this
to *_DEFAULT to better indicate its meaning.
This paves the way for _NONE to really mean "no status".
Signed-off-by: Tay Ray Chuan
---
Michael Haggerty writes:
> Give the poor humans some names to help them make sense of things.
>
> Signed-off-by: Michael Haggerty
> ---
Good.
Reviewed-by: me.
> replace_object.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/replace_object.c b/rep
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
> ---
> cache.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/cache.h b/cache.h
> index dc040fb..0ecd1c8 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -788,13 +788,29 @@ static inline void *read_sha1_file(cons
Jeff King writes:
> On Fri, Feb 21, 2014 at 06:47:47AM +0700, Nguyễn Thái Ngọc Duy wrote:
>
>> This delta_stack array can grow to any length depending on the actual
>> delta chain, but we forget to free it. Normally it does not matter
>> because we use small_delta_stack[] from stack and small_del
Max Horn writes:
>> Thanks. Let's keep it a bit longer and see how your new
>> investigation (and possibly help from others) develops to a
>> solution.
>
> So I had a closer look, and I now believe to now understand what
> the right fix is. Simply dropping transport-helper: check for
> 'forced u
Duy Nguyen writes:
> Why not reversed order? So its syntax could be
>
> [ "-" ] FIELD [ ":" [ "version" | "v" ] ]
>
> It fits better to current f-e-r syntax where modifiers are after the
> colon. And it avoids the possibility that someone adds field "version"
> and we can't tell what "version" is
Duy Nguyen writes:
> For old projects, commits older than 1-2 years is probably less often
> accessed and could use some aggressive packing.
I used to repack older part of history manually with a deeper depth,
mark the result with the .keep bit, and then repack the whole thing
again to have the
Document --keep-index's short form -k in both main synopsis and
the save synopsis in the Options section.
Signed-off-by: John Marshall
---
A very small documentation patch: I'd not read the main synopsis
carefully (just skipped to the save details!) and didn't realise
that --keep-index had a sho
Christian Jaeger writes:
> Also, in "man git-gc" document --aggressive that it leads to slower
> *read* performance after the gc, I remember having red that option's
> docs when I ran it, and since it didn't mention that it makes reads
> slower, I didn't expect it to, and thus didn't remember thi
On Fri, 21 Feb 2014, Michael Haggerty wrote:
> Signed-off-by: Michael Haggerty
Minor nits below.
> ---
> object.c | 23 ++-
> object.h | 7 +++
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/object.c b/object.c
> index 584f7ac..c34e225 100644
> -
On Fri, 21 Feb 2014, Michael Haggerty wrote:
> Signed-off-by: Michael Haggerty
Acked-by: Nicolas Pitre
> ---
> cache.h | 66
> ++---
> sha1_file.c | 26 +---
> 2 files changed, 78 insertions(+), 14 deletions(-)
On Fri, 21 Feb 2014, Michael Haggerty wrote:
> Add a comment at the declaration of last_found_pack and where it is
> used in find_pack_entry(). In the latter, separate the cases (1) to
> make a place for the new comment and (2) to turn the success case into
> affirmative logic.
>
> Signed-off-by
Signed-off-by: Michael Haggerty
---
cache.h | 66 ++---
sha1_file.c | 26 +---
2 files changed, 78 insertions(+), 14 deletions(-)
diff --git a/cache.h b/cache.h
index 1663478..e62fdec 100644
--- a/cache.h
+++ b/cache
Signed-off-by: Michael Haggerty
---
object.c | 23 ++-
object.h | 7 +++
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/object.c b/object.c
index 584f7ac..c34e225 100644
--- a/object.c
+++ b/object.c
@@ -43,14 +43,26 @@ int type_from_string(const char *str
Change the return value of sha1_file_name() to (const char *).
(Callers have no business mucking about here.) Change callers
accordingly, deleting a few superfluous temporary variables along the
way.
Signed-off-by: Michael Haggerty
---
cache.h | 2 +-
http.c | 2 +-
sha1_file.c | 24
Give the poor humans some names to help them make sense of things.
Signed-off-by: Michael Haggerty
---
replace_object.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/replace_object.c b/replace_object.c
index cdcaf8c..6fc3ff4 100644
--- a/replace_object.c
Add a comment at the declaration of last_found_pack and where it is
used in find_pack_entry(). In the latter, separate the cases (1) to
make a place for the new comment and (2) to turn the success case into
affirmative logic.
Signed-off-by: Michael Haggerty
---
sha1_file.c | 16
Signed-off-by: Michael Haggerty
---
cache.h | 16
1 file changed, 16 insertions(+)
diff --git a/cache.h b/cache.h
index dc040fb..0ecd1c8 100644
--- a/cache.h
+++ b/cache.h
@@ -788,13 +788,29 @@ static inline void *read_sha1_file(const unsigned char
*sha1, enum object_type *
{
I was reading around in the neighborhood of fsck, objects, and packs
and I had the familiar and discouraging experience of having to read
code all the way up and down the callstack to understand *anything*.
Please let's all make more of an effort to document functions,
especially things that are no
Junio C Hamano wrote:
> * jk/branch-at-publish-rebased (2014-01-17) 5 commits
> - t1507 (rev-parse-upstream): fix typo in test title
> - implement @{publish} shorthand
> - branch_get: provide per-branch pushremote pointers
> - branch_get: return early on error
> - sha1_name: refactor upstream_
On 2014-02-21 15.42, Robert Dailey wrote:
> I'm converting a large SVN repository to a Git repository. I've run
> the first step of `git svn fetch` and now I have all of my branches,
> tags, and trunk. However my tags are still just branches, I have not
> converted them yet.
>
> As I transition my
On 2014-02-21 10.55, Max Horn wrote:
>
> On 20.02.2014, at 20:22, Junio C Hamano wrote:
>
>> Max Horn writes:
>>
>>> On 19.02.2014, at 22:41, Junio C Hamano wrote:
>>>
* fc/transport-helper-fixes (2013-12-09) 6 commits
- remote-bzr: support the new 'force' option
- test-hg.sh: t
git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
Use the hgrc configuration file in the internal mercurial repository in
addition to the other system wide hgrc files. This is done by using the
'ui' object from the 'repository' object which will have loaded the
repository hgrc file
I'm converting a large SVN repository to a Git repository. I've run
the first step of `git svn fetch` and now I have all of my branches,
tags, and trunk. However my tags are still just branches, I have not
converted them yet.
As I transition my team over to use Git, I wonder if it is possible to
c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
I can't think of any case that progress lines are for machine. It
started because of the only local untranslated line in "git clone".
But I think we should do all at once.
builtin/fsck.c | 6 +++---
builtin/pack-objects.c | 6 +++---
builtin
On Fri, Feb 21, 2014 at 3:43 AM, Jeff King wrote:
> I think I actually prefer the full word "version", as you have already.
> It's clear what it means, and we can extend the syntax generally to:
Agreed. It's hard to find a letter that reminds you about "version".
>
> --sort=[-][comparison:]fie
On Mon, Feb 17, 2014 at 03:14:01PM -0700, Paul Lotz wrote:
> From the Git Bash command line, I enter
> $ git difftool
>
> and type y when the file I want to difference appears. Git correctly
> calls the external diff tool (LVCompare.exe), but the path for the remote
> file Git passes to that to
On 20.02.2014, at 20:22, Junio C Hamano wrote:
> Max Horn writes:
>
>> On 19.02.2014, at 22:41, Junio C Hamano wrote:
>>
>>> * fc/transport-helper-fixes (2013-12-09) 6 commits
>>> - remote-bzr: support the new 'force' option
>>> - test-hg.sh: tests are now expected to pass
>>> - transport-he
On Thu, Feb 20, 2014 at 02:41:23PM -0800, David Aguilar wrote:
> On Thu, Feb 20, 2014 at 1:03 PM, Jens Lehmann wrote:
> > Sorry for the late reply, but here we go ...
> >
> > Am 10.02.2014 07:33, schrieb Gábor Lipták:
> >> Hi Jens,
> >>
> >> So "git status" says:
> >>
> >> liptak@liptak-kubuntu:~/
44 matches
Mail list logo
