On Thu, Feb 20, 2014 at 02:41:23PM -0800, David Aguilar wrote:
On Thu, Feb 20, 2014 at 1:03 PM, Jens Lehmann jens.lehm...@web.de 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:
On 20.02.2014, at 20:22, Junio C Hamano gits...@pobox.com wrote:
Max Horn m...@quendi.de writes:
On 19.02.2014, at 22:41, Junio C Hamano gits...@pobox.com wrote:
* fc/transport-helper-fixes (2013-12-09) 6 commits
- remote-bzr: support the new 'force' option
- test-hg.sh: tests are now
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 tool is
On Fri, Feb 21, 2014 at 3:43 AM, Jeff King p...@peff.net 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.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
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
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
On 2014-02-21 10.55, Max Horn wrote:
On 20.02.2014, at 20:22, Junio C Hamano gits...@pobox.com wrote:
Max Horn m...@quendi.de writes:
On 19.02.2014, at 22:41, Junio C Hamano gits...@pobox.com wrote:
* fc/transport-helper-fixes (2013-12-09) 6 commits
- remote-bzr: support the new 'force'
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 team
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_mark
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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,
Give the poor humans some names to help them make sense of things.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
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 mhag...@alum.mit.edu
---
sha1_file.c
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
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 mhag...@alum.mit.edu
---
cache.h | 2 +-
http.c | 2
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
---
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:
On Fri, 21 Feb 2014, Michael Haggerty wrote:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Acked-by: Nicolas Pitre n...@fluxnic.net
---
cache.h | 66
++---
sha1_file.c | 26 +---
2 files changed, 78
On Fri, 21 Feb 2014, Michael Haggerty wrote:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
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
Christian Jaeger chr...@gmail.com 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
Document --keep-index's short form -k in both main synopsis and
the save synopsis in the Options section.
Signed-off-by: John Marshall j...@sanger.ac.uk
---
A very small documentation patch: I'd not read the main synopsis
carefully (just skipped to the save details!) and didn't realise
that
Duy Nguyen pclo...@gmail.com 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
Duy Nguyen pclo...@gmail.com 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
Max Horn m...@quendi.de 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
Jeff King p...@peff.net 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
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
Michael Haggerty mhag...@alum.mit.edu writes:
Give the poor humans some names to help them make sense of things.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Good.
Reviewed-by: me.
replace_object.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
Cc: Jeff King p...@peff.net
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
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
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
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
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
Tay Ray Chuan rcta...@gmail.com 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
Junio C Hamano gits...@pobox.com writes:
Thomas Gummerer t.gumme...@gmail.com 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.
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
On Wed, Feb 19, 2014 at 3:59 AM, Junio C Hamano gits...@pobox.com 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.
On 21.02.2014, at 19:04, Junio C Hamano gits...@pobox.com 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
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
--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
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
From: Ryan Schmitt rschm...@u.rochester.edu
This makes git-rm more consistent with git-diff, which also accepts
--staged as a synonym of --cached.
Signed-off-by: Ryan Schmitt rschm...@pobox.com
---
Documentation/git-rm.txt | 2 +-
builtin/rm.c | 1 +
t/t3600-rm.sh| 6
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 work
44 matches
Mail list logo
