A submodule's object database may be imported to in-core object pool
for a quick peek without paying the price of running a separate git
command. These databases are marked in for stricter checks later to
avoid accidentially refering to a submodule's SHA-1 from main repo
(except in gitlinks).
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
sha1_file.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/sha1_file.c b/sha1_file.c
index af71122..5948dcb 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2615,12 +2615,46 @@ static int
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
sha1_file.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/sha1_file.c b/sha1_file.c
index 5948dcb..ec3a040 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2643,6 +2643,29 @@ static void
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
sha1_file.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/sha1_file.c b/sha1_file.c
index ec3a040..01681e5 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2666,6 +2666,12 @@ static void check_sha1_file_for_external_source(const
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
read-cache.c | 20
1 file changed, 20 insertions(+)
diff --git a/read-cache.c b/read-cache.c
index fda78bc..4579215 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1720,6 +1720,26 @@ static int
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
refs.c | 24
1 file changed, 24 insertions(+)
diff --git a/refs.c b/refs.c
index 541fec2..86003af 100644
--- a/refs.c
+++ b/refs.c
@@ -2014,6 +2014,18 @@ static int log_ref_write(const char *refname, const
Wf!
Reroll my patches again after 1.5 years ;)
They must be applied against v1.8.1.1
Sorry for my laziness ;)
Alexey Shumkin (4):
t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
t7102 (reset): refactoring: don't hardcode SHA-1 in expected outputs
pretty: Add failing
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
t/t6006-rev-list-format.sh | 130 +
1 file changed, 72 insertions(+), 58 deletions(-)
diff --git
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
t/t7102-reset.sh | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git
The following two commands are expected to give the same output to a terminal:
$ git log --oneline --no-color
$ git log --pretty=format:'%h %s'
However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it format %s.
Log messages
Junio C Hamano gits...@pobox.com wrote:
Eric Wong normalper...@yhbt.net writes:
diff --git a/git-svn.perl b/git-svn.perl
index c232798..e5bd292 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -332,11 +332,13 @@ if ($cmd $cmd =~ /(?:clone|init|multi-init)$/) {
I've squashed the change I mentioned in
http://mid.gmane.org/20130124101417.ga22...@dcvr.yhbt.net
to Barry's commit, and added Jonathan's Reviewed-by to my cleanup
commit.
The following changes since commit ec3ae6ec46ed48383ae40643990f169b65a563cc:
Merge git://ozlabs.org/~paulus/gitk
Bump
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 21.01.2013 09:26 schrieb Sven Strickroth:
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
- The
Am 23.01.2013 21:02, schrieb Jeff King:
On Wed, Jan 23, 2013 at 03:38:16PM +0100, Armin wrote:
Hello dear git people.
I experience a reproducible segmentation fault on one of my
repositories when doing a git log --submodule -p, tested with newest
version on Arch Linux (git version 1.8.1.1)
Am Donnerstag, 24. Januar 2013 14:40:47 schrieb Duy Nguyen:
On Thu, Jan 24, 2013 at 7:11 PM, Stefan Näwe
stefan.na...@atlas-elektronik.com wrote:
Does it fail with older versions of git? If so, can you bisect?
I did. My bisection told me this is the suspect:
ccdc603 (parse_object: try
On Thu, Jan 24, 2013 at 9:06 PM, Stefan Näwe
stefan.na...@atlas-elektronik.com wrote:
Am Donnerstag, 24. Januar 2013 14:40:47 schrieb Duy Nguyen:
On Thu, Jan 24, 2013 at 7:11 PM, Stefan Näwe
stefan.na...@atlas-elektronik.com wrote:
Does it fail with older versions of git? If so, can you
Jeff King p...@peff.net writes:
The ensure_commit_buffer function could look something like:
int ensure_commit_buffer(struct commit *item)
{
enum object_type type;
unsigned long size;
if (!item)
return -1;
if
Jeff King p...@peff.net writes:
I wonder if we can reword it to explain more about why we do not have
the object, without getting too inaccurate. Something like:
Updates were rejected because the remote contains objects that you do
not have locally. This is usually caused by another
Jeff King p...@peff.net writes:
And yeah, this should use lookup_unknown_object to extend the
optimization to mark_our_ref (and avoid removing it for the
ref-advertisement case, of course).
Thanks for sanity checking. Here is what is queued at the bottom of
the hide-refs topic.
-- 8 --
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
We currently know if an object is loose or packed. We do not know if
it's from the repo's object database, or via alternates
mechanism. With this patch, sha1_object_info_extended() can tell if an
object comes from alternates source (and which
Alexey Shumkin alex.crez...@gmail.com writes:
Bump
Bump what???
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Duy Nguyen pclo...@gmail.com writes:
I don't think we need to support two different sets of wildcards in
the long run. I'm thinking of adding :(glob) with WM_PATHNAME.
Pathspec without :(glob) still uses the current wildcards (i.e. no
FNM_PATHNAME). At some point, like 2.0, we either switch
When handling a symlink conflict or a deleted-file conflict, mergetool
stops to ask the user what to do. If the user chooses any option besides
(a)bort, then the temporary files which mergetool created in
preparation for handling the conflict are removed. But these temporary
files are not removed
I've meant you did not reply to my last message in this thread
http://thread.gmane.org/gmane.comp.version-control.git/181791
2013/1/24 Junio C Hamano gits...@pobox.com
Alexey Shumkin alex.crez...@gmail.com writes:
Bump
Bump what???
--
To unsubscribe from this list: send the line
Shumkin Alexey alex.crez...@gmail.com writes:
I've meant you did not reply to my last message in this thread
http://thread.gmane.org/gmane.comp.version-control.git/181791
Please repost the patch (with possible updates) for review when
attempting to resurrect an ancient topic, instead of
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
read-cache.c | 20
1 file changed, 20 insertions(+)
diff --git a/read-cache.c b/read-cache.c
index fda78bc..4579215 100644
--- a/read-cache.c
+++ b/read-cache.c
git-cvsimport relies on version 2 of cvsps and does not work with the
new version 3. Since cvsps 3.x does not currently work as well as
version 2 for incremental import, document this fact.
Specifically, there is no way to make new git-cvsimport that supports
cvsps 3.x and have a seamless
Sven Strickroth sven.strickr...@tu-clausthal.de writes:
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
Phil Hord ho...@cisco.com writes:
When handling a symlink conflict or a deleted-file conflict, mergetool
stops to ask the user what to do. If the user chooses any option besides
(a)bort, then the temporary files which mergetool created in
preparation for handling the conflict are removed.
The --tool-help option to git-difftool currently displays incorrect
output since it uses the names of the files in
$GIT_EXEC_PATH/mergetools/ rather than the list of command names in
git-mergetool--lib.
This series fixes this by changing it to simply delegate to a function
in git-mergetool--lib.
When using show_tool_help from git-difftool we will want it to print
git difftool not git mergetool so use git ${TOOL_MODE}tool.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-mergetool--lib.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
The --tool-help option to git-difftool currently displays incorrect
output since it uses the names of the files in
$GIT_EXEC_PATH/mergetools/ rather than the list of command names in
git-mergetool--lib.
Fix this by simply delegating the --tool-help argument to the
show_tool_help function in
John Keeping j...@keeping.me.uk writes:
git-cvsimport relies on version 2 of cvsps and does not work with the
new version 3. Since cvsps 3.x does not currently work as well as
version 2 for incremental import, document this fact.
Specifically, there is no way to make new git-cvsimport that
On Thu, Jan 24, 2013 at 12:04:11PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
git-cvsimport relies on version 2 of cvsps and does not work with the
new version 3. Since cvsps 3.x does not currently work as well as
version 2 for incremental import, document this
Alexey Shumkin alex.crez...@gmail.com writes:
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
t/t6006-rev-list-format.sh | 130
+
1 file
Alexey Shumkin alex.crez...@gmail.com writes:
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
Looks good ( refactoring: in the title may not want to be there,
though).
Thanks.
Alexey Shumkin alex.crez...@gmail.com writes:
The following two commands are expected to give the same output to a terminal:
$ git log --oneline --no-color
$ git log --pretty=format:'%h %s'
However, the former pays attention to i18n.logOutputEncoding
configuration, while the
John Keeping j...@keeping.me.uk writes:
On Thu, Jan 24, 2013 at 12:04:11PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
git-cvsimport relies on version 2 of cvsps and does not work with the
new version 3. Since cvsps 3.x does not currently work as well as
Alexey Shumkin alex.crez...@gmail.com writes:
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index c248509..4db43a4 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
...
@@ -112,12 +133,12 @@ commit $head2
commit $head1
EOF
-test_format
Nice code reduction ;-)
Thanks, will queue.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2013-01-23, at 23:07, Jeff King p...@peff.net wrote:
On Wed, Jan 23, 2013 at 01:25:04PM -0800, Jonathon Mah wrote:
Several areas of code would free buffers for object structs that
contained them (struct tree and struct commit), but without clearing
the parsed flag. parse_object would
In test mode, git completion should propose commands only if they
belong to the list of authorized commands.
Signed-off-by: Jean-Noel Avila jn.av...@free.fr
---
Better show some code than try to explain. Here is what I mean by
filter the output git help -a.
On Thu, Jan 24, 2013 at 2:54 PM, Junio C Hamano gits...@pobox.com wrote:
Phil Hord ho...@cisco.com writes:
When handling a symlink conflict or a deleted-file conflict, mergetool
stops to ask the user what to do. If the user chooses any option besides
(a)bort, then the temporary files which
Jean-Noël AVILA jn.av...@free.fr writes:
In test mode, git completion should propose commands only if they
belong to the list of authorized commands.
Signed-off-by: Jean-Noel Avila jn.av...@free.fr
---
Better show some code than try to explain. Here is what I mean by
filter the output git
Le jeudi 24 janvier 2013 22:46:13, Junio C Hamano a écrit :
Jean-Noël AVILA jn.av...@free.fr writes:
In test mode, git completion should propose commands only if they
belong to the list of authorized commands.
Signed-off-by: Jean-Noel Avila jn.av...@free.fr
---
Better show some
Am 24.01.2013 20:51 schrieb Junio C Hamano:
Sven Strickroth sven.strickr...@tu-clausthal.de writes:
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with
Sven Strickroth sven.strickr...@tu-clausthal.de writes:
Am 24.01.2013 20:51 schrieb Junio C Hamano:
Sven Strickroth sven.strickr...@tu-clausthal.de writes:
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one
Jean-Noël AVILA jn.av...@free.fr writes:
My rational was to be sure to put the environment variable out of the
way once the script has been sourced. I can make two alternative
definitions of __git_list_all_commands () depending on the presence of
$AUTHORIZED_CMD_LIST if you are worried
On Wed, Jan 23, 2013 at 4:55 PM, Junio C Hamano gits...@pobox.com wrote:
The nonfastforward and update fields are only used while
deciding what value to assign to the status locally in a single
function. Remove them from the struct ref.
The requires_force field is not used to decide if the
Le jeudi 24 janvier 2013 23:29:33, Junio C Hamano a écrit :
Jean-Noël AVILA jn.av...@free.fr writes:
My rational was to be sure to put the environment variable out of the
way once the script has been sourced. I can make two alternative
definitions of __git_list_all_commands () depending
When you have random build artifacts in your build directory, left
behind by running make while on another branch, the git help -a
command run by __git_list_all_commands in the completion script that
is being tested does not have a way to know that they are not part
of the subcommands this build
On Thu, Jan 24, 2013 at 09:14:47PM +0700, Nguyen Thai Ngoc Duy wrote:
I did. My bisection told me this is the suspect:
ccdc603 (parse_object: try internal cache before reading object db)
diff --git a/object.c b/object.c
index d8d09f9..6b06297 100644
--- a/object.c
+++ b/object.c
On 2013-01-23, at 23:07, Jeff King p...@peff.net wrote:
On Wed, Jan 23, 2013 at 01:25:04PM -0800, Jonathon Mah wrote:
Several areas of code would free buffers for object structs that
contained them (struct tree and struct commit), but without clearing
the parsed flag. parse_object would
Jeff King p...@peff.net writes:
... (e.g., how should log know that a submodule diff might later want
to see the same entry? Should we optimistically free and then make it
easier for the later user to reliably ensure the buffer is primed? Or
should we err on the side of keeping it in place?).
On Thu, Jan 24, 2013 at 03:56:23PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... (e.g., how should log know that a submodule diff might later want
to see the same entry? Should we optimistically free and then make it
easier for the later user to reliably ensure the
On Thu, Jan 24, 2013 at 03:21:46PM -0800, Jonathan Nieder wrote:
This broke /etc/mailname handling. Before:
$ git var GIT_COMMITTER_IDENT
Jonathan Nieder j...@mailname.example.com 1359069165 -0800
After:
$ git var GIT_COMMITTER_IDENT
Jonathan Nieder
On Thu, Jan 24, 2013 at 03:07:42PM -0800, Junio C Hamano wrote:
When you have random build artifacts in your build directory, left
behind by running make while on another branch, the git help -a
command run by __git_list_all_commands in the completion script that
is being tested does not have
On Fri, Jan 25, 2013 at 12:45 AM, Junio C Hamano gits...@pobox.com wrote:
How about this way instead: we keep track of where objects come from
so we can verify object source when we create or update something
that contains SHA-1.
The overall approach taken by this series may be worth
On Fri, Jan 25, 2013 at 1:22 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
I don't think we need to support two different sets of wildcards in
the long run. I'm thinking of adding :(glob) with WM_PATHNAME.
Pathspec without :(glob) still uses the current
On Fri, Jan 25, 2013 at 2:15 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
read-cache.c | 20
1 file changed, 20 insertions(+)
diff --git a/read-cache.c
On Fri, Jan 25, 2013 at 7:55 AM, Jeff King p...@peff.net wrote:
On Thu, Jan 24, 2013 at 03:56:23PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... (e.g., how should log know that a submodule diff might later want
to see the same entry? Should we optimistically free and
Jeff King wrote:
On Thu, Jan 24, 2013 at 03:07:42PM -0800, Junio C Hamano wrote[1]:
Instrument the completion script and give it a way for us to tell
what (subset of) subcommands we are going to ship.
[...]
The only thing I might add is a test just to double-check that git help
-a is parsed
Commit v1.8.1-rc0-3-gfa2364e renamed merge-file.h to merge-blobs.h, but
forgot to update the reference of merge-file.h in Makefile. This would
break the build of po/git.pot, which depends on $(LOCALIZED_C), then
fallback to the missing file merge-file.h.
Signed-off-by: Jiang Xin
Duy Nguyen pclo...@gmail.com writes:
On Fri, Jan 25, 2013 at 12:45 AM, Junio C Hamano gits...@pobox.com wrote:
How about this way instead: we keep track of where objects come from
so we can verify object source when we create or update something
that contains SHA-1.
The overall approach
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
... (e.g., how should log know that a submodule diff might later want
to see the same entry? Should we optimistically free and then make it
easier for the later user to reliably ensure the buffer is primed? Or
should
On Fri, Jan 25, 2013 at 10:58 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Fri, Jan 25, 2013 at 12:45 AM, Junio C Hamano gits...@pobox.com wrote:
How about this way instead: we keep track of where objects come from
so we can verify object source when
On Thu, Jan 24, 2013 at 07:59:58PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
... (e.g., how should log know that a submodule diff might later want
to see the same entry? Should we optimistically free and then make it
easier
Jeff King p...@peff.net writes:
This looks good to me.
The only thing I might add is a test just to double-check that git help
-a is parsed correctly. Like:
test_expect_success 'command completion works without test harness' '
GIT_TESTING_COMMAND_COMPLETION= run_completion git
On Thu, Jan 24, 2013 at 08:11:07PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
This looks good to me.
The only thing I might add is a test just to double-check that git help
-a is parsed correctly. Like:
test_expect_success 'command completion works without test
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
This looks good to me.
The only thing I might add is a test just to double-check that git help
-a is parsed correctly. Like:
test_expect_success 'command completion works without test harness' '
Jeff King p...@peff.net writes:
... I know it gets the job done, but in my
experience, macros which do not behave syntactically like functions are
usually a good sign that you are doing something gross and
unmaintainable.
Yeah, it is a bit too cute for my taste, too, even though it was fun
On Thu, Jan 24, 2013 at 08:19:30PM -0800, Junio C Hamano wrote:
Ahh, ok, we show one element per line and just make sure bundle
is there, and we do not care what other buns appear in the output.
Not so quick, though. The lower level read from help -a is only
run once and its output kept
On Wed, Jan 23, 2013 at 3:55 PM, Junio C Hamano gits...@pobox.com wrote:
This builds on Chris Rorvick's earlier effort to forbid unforced
updates to refs/tags/ hierarchy and giving sensible error and advise
messages for that case (we are not rejecting such a push due to fast
forwardness, and
Dear l10n team members,
New git.pot is generated from v1.8.1-476-gec3ae6e in the master branch.
l10n: Update git.pot (11 new, 7 removed messages)
Generate po/git.pot from v1.8.1-476-gec3ae6e, and there are 11 new and 7
removed messages.
Signed-off-by: Jiang Xin
Duy Nguyen pclo...@gmail.com writes:
On Fri, Jan 25, 2013 at 1:22 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
I don't think we need to support two different sets of wildcards in
the long run. I'm thinking of adding :(glob) with WM_PATHNAME.
Pathspec
On Wed, Jan 23, 2013 at 3:12 PM, John Keeping j...@keeping.me.uk wrote:
The existing script (git-cvsimport.perl) won't ever work with cvsps-3
since features it relies on have been removed.
Not reporting the ancestry branch seems to be the big one. Are there
others? I had a version of the Perl
Oops, I find it is already fixed in commit
a60521bc6099ce89d05ef2160d2e3c30a106fda7.
commit a60521bc6099ce89d05ef2160d2e3c30a106fda7
Author: Ramsay Jones ram...@ramsay1.demon.co.uk
Date: Tue Jan 22 16:47:47 2013 +
Makefile: Replace merge-file.h with merge-blobs.h in LIB_H
Commit
Chris Rorvick ch...@rorvick.com writes:
Had I written the the already exists advice in the context of these
additional statuses I would have said the destination *tag* reference
already exists, or maybe even just the destination *tag* already
exists.
Yeah, now we do not use already exists
On Thu, Jan 24, 2013 at 11:04 PM, Junio C Hamano gits...@pobox.com wrote:
Would it be sufficient to do this? I think the tag already exists
in the remote is already clear that we are talking about the
destination.
Good point.
diff --git a/builtin/push.c b/builtin/push.c
index
On Wed, Jan 23, 2013 at 11:16 PM, Alexey Shumkin alex.crez...@gmail.com wrote:
Options are taken from Git source/mergetools/vim
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
git-gui/lib/mergetool.tcl | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
A better long-term
On Thu, Jan 24, 2013 at 11:55 AM, John Keeping j...@keeping.me.uk wrote:
The --tool-help option to git-difftool currently displays incorrect
output since it uses the names of the files in
$GIT_EXEC_PATH/mergetools/ rather than the list of command names in
git-mergetool--lib.
Fix this by
Hi,
Junio C Hamano wrote:
I've been toying with an idea along this line.
Heh. Just for fun, here's an uglier version:
struct wcb_data {
int had_buffer;
int using_buffer;
};
#define WITH_COMMIT_BUFFER_DATA_INIT { 0, 0 }
extern
All your family members can be * links of london sale
http://www.cheaplinksoflondonshops.co.uk/ * quite exclusive rear. While
getaways, 1st birthdays plus backlinks involving manchester substitute
gift-giving characteristics surface, you'll want to present the most
beneficial for you to all
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index aa258a6..63d4904 100644
--- a/.gitignore
+++ b/.gitignore
@@ -171,6 +171,7 @@
/git-whatchanged
/git-write-tree
/git-core-*/?*
On Thu, Jan 24, 2013 at 2:15 PM, Junio C Hamano gits...@pobox.com wrote:
Sven Strickroth sven.strickr...@tu-clausthal.de writes:
Am 24.01.2013 20:51 schrieb Junio C Hamano:
Sven Strickroth sven.strickr...@tu-clausthal.de writes:
- The TortoiseGit team renamed TortoiseMerge.exe to
That picture, Avatar, contains earn very good worldwide recognition
throughout the world, additionally, the exquisite Pandora intercontinental
from this picture catches a persons vision of most many people. Pandora
develops into the latest ideas fairly recently, it is utilized for a number
of
Anytime people speaks about superior wineglass job, any identity Tiffany
without delay arrives at thought process. * tiffany uk
http://www.tiffanyandcosales.co.uk/ * has got earned terrific attraction
meant for about seventy-five together with 20 years. It had become involving
some sort of
David Aguilar dav...@gmail.com writes:
Even though the old tortoisemerge and the new tortoisegitmerge
have completely different syntax, could we still use the existence
of one when deciding which syntax to use?
...
...and then later merge_cmd and diff_cmd
can delegate to
Jonathan Nieder jrnie...@gmail.com writes:
Hi,
Junio C Hamano wrote:
I've been toying with an idea along this line.
Heh. Just for fun, here's an uglier version:
Much nicer, though.
struct wcb_data {
int had_buffer;
int using_buffer;
};
Just to note, the proposals so far don't prevent a smart-ass function from
freeing the buffer when it's called underneath the use/release scope, as in:
with_commit_buffer(commit); {
fn1_needing_buffer(commit);
walk_rev_tree_or_something();
fn2_needing_buffer(commit);
}
On Thu, Jan 24, 2013 at 11:21 PM, Junio C Hamano gits...@pobox.com wrote:
David Aguilar dav...@gmail.com writes:
This paragraph needs to be rewritten to unconfuse readers. The
original is barely intelligible, and it becomes unreadable as the
set of tools subtracted by minus and added by plus
92 matches
Mail list logo
