Junio C Hamano writes:
> "Philip Oakley" writes:
>
>>> +test_expect_success 'reroll count (-v)' '
>>> + rm -fr patches &&
>>> + git format-patch -o patches --cover-letter -v 4 master..side >list
>>> &&
>>
>> Shouldn't this be using the sticked form -v4 as described in the
>> commit message and g
From: "Junio C Hamano" Sent: Wednesday, January 02,
2013 10:42 PM
Accept "-v" as a synonym to "--reroll-count", so that users can say
"git format-patch -v4 master", instead of having to fully spell it
out as "git format-patch --reroll-count=4 master".
Signed-off-by: Junio C Hamano
---
* As I d
Hi,
Git is authenticating to my corporate proxy correctly, but is hanging
after "resolving deltas".
This is when cloning via HTTPS.
Apologies for linking to a Gist, but I'm having difficulty getting
this list to accept a log file attachment.
See https://gist.github.com/4448684 for the curl log.
"Philip Oakley" writes:
>> +test_expect_success 'reroll count (-v)' '
>> + rm -fr patches &&
>> + git format-patch -o patches --cover-letter -v 4 master..side >list
>> &&
>
> Shouldn't this be using the sticked form -v4 as described in the
> commit message and gitcli?
I personally do not care to
On Thu, Jan 3, 2013 at 11:37 AM, Michael Haggerty wrote:
> Hi,
>
> I've been thinking lately about how to attack difficult git merge
> conflicts. The first step is to visualize them. I have written some
> articles [1,2,3] describing a way to atomize a complicated merge and
> efficiently compute
Any thoughts on this idea? Is it flawed? I am trying to
write it up in a more formal generalized manner and was
hoping to get at least one "it seems sane" before I do.
Thanks,
-Martin
On Monday, December 31, 2012 03:30:53 am Martin Fick wrote:
> On Thursday, December 27, 2012 04:11:51 pm Mar
> The updated code structure is much nicer than the previous round,
> but I am somewhat puzzled how return value of remove_dirs() and
> &gone relate to each other. Surely when gone is set to zero,
> remove_dirs() is reporting that the directory it was asked to remove
> recursively did not go away,
Jeff King writes:
> Oh, I agree it's insane to try to carry through unmerged entries. I'm
> just concerned that not all code paths are careful enough to check.
I would actually be surprised if some code path do assume somebody
might give them an index with conflicting entries in it and guard
aga
On Thu, Jan 03, 2013 at 02:20:31PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Not surprising for such a large refactoring, but this has conflicts with
> > what's in next. Here's the patch to apply on top of the conflicted tree
> > you get from merging this with "next":
>
> Yeah, ver
Jeff King writes:
> Not surprising for such a large refactoring, but this has conflicts with
> what's in next. Here's the patch to apply on top of the conflicted tree
> you get from merging this with "next":
Yeah, verifying the manual fixup is a bit tricky indeed. The output from
$ git blame
On Thu, Jan 03, 2013 at 04:05:41PM -0500, Jeff King wrote:
> On Thu, Jan 03, 2013 at 03:32:22PM -0500, Jeff King wrote:
>
> > I think the usefulness is that it can be set by default for a particular
> > uname, so people on Windows can just type "make install-doc" without
> > having to care about
On Thu, Jan 03, 2013 at 03:32:22PM -0500, Jeff King wrote:
> I think the usefulness is that it can be set by default for a particular
> uname, so people on Windows can just type "make install-doc" without
> having to care about setting anything (though to be honest, I do not
> even know what they
Hi,
While struggling to get git-p4 to work properly with branches, I
thought the documentation on http://git-scm.com/docs/git-p4 could use
some improvements:
1. At the end of the "Branch detection" section, the following
commands are provided (for when you want to explicitly provide branch
mappin
Michael Haggerty :
> There are two good reasons that the output is written to two separate files:
Those are good reasons to write to a pair of tempfiles, and I was able
to deduce in advance most of what your explanation would be from the
bare fact that you did it that way.
They are *not* good rea
On Thu, Jan 3, 2013 at 2:33 AM, Johannes Sixt wrote:
> Am 03.01.2013 10:50, schrieb Grégory Pakosz:
>>>
>>> IOW, if the command was something like
>>>
>>> git filter-branch ...filter options... -- v1.0 master ...
>>>
>>> and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be
>>
The flow described in the document is still correct, but over time I
have automated various parts of the workflow with tools and their
use was not explained at all.
Update it and outline the use of two key scripts from the 'todo'
branch, "Reintegrate" and "cook".
Signed-off-by: Junio C Hamano
--
On Thu, Jan 03, 2013 at 03:32:22PM -0500, Jeff King wrote:
> On Thu, Jan 03, 2013 at 11:05:18AM -0800, Junio C Hamano wrote:
>
> > This allows things like:
> >
> > $ DEFAULT_DOC_TARGET=html make doc
> > $ DEFAULT_DOC_INSTALL_TARGET=html make install-doc
> >
> > on a platform that does not h
On Thu, Jan 03, 2013 at 12:34:27PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Or are you suggesting that the three-way case should always be protected
> > by checking that there are no unmerged entries before we start it? That
> > seems sane to me, but I haven't confirmed that that i
Jeff King writes:
> Or are you suggesting that the three-way case should always be protected
> by checking that there are no unmerged entries before we start it? That
> seems sane to me, but I haven't confirmed that that is the case.
I think the normal (and hopefully only) "-m -u O A B" use case
On Thu, Jan 03, 2013 at 11:05:18AM -0800, Junio C Hamano wrote:
> This allows things like:
>
> $ DEFAULT_DOC_TARGET=html make doc
> $ DEFAULT_DOC_INSTALL_TARGET=html make install-doc
>
> on a platform that does not have manpage viewer. Which is not very
> useful, given that you can already
On Thu, Jan 03, 2013 at 07:34:53AM -0800, Junio C Hamano wrote:
> > Good point; I was just thinking about the --reset case.
> >
> > With "-m", though, we could in theory carry over the unmerged entries
> > (again, assuming that "old" and "new" are the same; otherwise it is an
> > obvious reject).
On 01/03/2013 07:27 PM, Greg Troxel wrote:
>
> Junio C Hamano writes:
>
>> I forgot to mention that we also ship configure (and keep track of
>> configure.ac) so that optionally people can let autoconf machinery
>> to create config.mak.autogen to be included at the same place as
>> handcrafted c
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The post 1.8.1 cycle has started, and about a dozen topics (mostly
fixes) have graduated to the 'master' branch. The second batch will
follow s
In a fashion similar to the previous DEFAULT_DOC_TARGET patch, teach
the build procedure to allow installing the documentation sets
specified via DEFAULT_DOC_INSTALL_TARGET.
These two symbols must be separate, as we should allow formatting
more than what will be installed. The default has been to
By default, "make doc" generates the manpages and htmldocs in the
Documentation directory, but you may want to change this depending
on the target environment, e.g. to include 'pdf'. Introduce a new
Makefile variable DEFAULT_DOC_TARGET to allow customizing this.
The primary motivation is to let u
This allows things like:
$ DEFAULT_DOC_TARGET=html make doc
$ DEFAULT_DOC_INSTALL_TARGET=html make install-doc
on a platform that does not have manpage viewer. Which is not very
useful, given that you can already say
$ make install-html
on such a platform, and these install-$format targe
Junio C Hamano writes:
> I forgot to mention that we also ship configure (and keep track of
> configure.ac) so that optionally people can let autoconf machinery
> to create config.mak.autogen to be included at the same place as
> handcrafted config.mak in their build process. I do not offhand
>
> Oh, that wasn't meant as a complaint. I am tempted to rewrite the
> log message like so, though:
>
> 65969d4 (merge: honor prepare-commit-msg hook, 2011-02-14) tried to
> make "git commit" and "git merge" consistent, because a merge that
> required user assistance has to be concluded
Hi,
I've been thinking lately about how to attack difficult git merge
conflicts. The first step is to visualize them. I have written some
articles [1,2,3] describing a way to atomize a complicated merge and
efficiently compute diagrams that show which pairwise commits cause the
merge to go awry.
On 01/03/2013 04:22 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>>> Doesn't Python come with a standard subprocess module that lets you
>>> spawn external programs safely, similar to the way Perl's list form
>>> open(), e.g. "open($fh, "-|", 'git', @args)", works?
>
> ... and of course
Greg Troxel writes:
> Junio C Hamano writes:
>
>> Greg Troxel writes:
>>
>>> I realize a README.foo file for N different systems could be clutter,
>>> but having these checked in would provide the concise help that people
>>> on any of those platforms need.
>>
>> Our Makefile documents knobs pe
We only try to get branch name in "format-patch origin" case or
similar and not "format-patch -22" where HEAD is automatically
added. Without correct branch name, branch description cannot be
added. Make sure we always get branch name.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
On Thu, Jan 3, 2013
On Sat, Dec 22, 2012 at 12:36 PM, Eric S. Raymond wrote:
> It is pure accident that I now maintain two of these.
Maintainership is always temporary.
> Having three different tools for this job seems to me duplicative and
> pointless; two of them should probably be let die an honorable death.
Pe
Nguyễn Thái Ngọc Duy writes:
> We only try to get branch name in "format-patch origin" case or
> similar and not "format-patch -22" where HEAD is automatically
> added. Without correct branch name, branch description cannot be
> added. Make sure we always get branch name.
>
> Signed-off-by: Nguy
On 12/22/2012 06:36 PM, Eric S. Raymond wrote:
> * One is Michael Haggerty's cvs2git. I had bad experiences with the
> cvs2svn code it's derived from in the past, but Michael believes those
> problems have been fixed and I will accept that - at least until I can
> test for myself. Its documented
Jeff King writes:
> On Tue, Jan 01, 2013 at 02:24:46PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > So I think we need to update twoway_merge to recognize unmerged entries,
>> > which gives us two options:
>> >
>> > 1. Reject the merge.
>> >
>> > 2. Throw away the current unm
Antoine Pelisse writes:
>> Doesn't Python come with a standard subprocess module that lets you
>> spawn external programs safely, similar to the way Perl's list form
>> open(), e.g. "open($fh, "-|", 'git', @args)", works?
... and of course a more boring "system('git', $subcmd, @args)", as well.
We only try to get branch name in "format-patch origin" case or
similar and not "format-patch -22" where HEAD is automatically
added. Without correct branch name, branch description cannot be
added. Make sure we always get branch name.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/log.c
find_branch_name() assumes to take refs/heads/. But we also
have symbolic refs, such as HEAD, that can point to a valid branch in
refs/heads and do not follow refs/heads/ syntax. Remove the
assumption and apply normal ref resolution. After all it would be
confusing if rev machinery resolves a ref i
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t4014-format-patch.sh | 21 +
1 file changed, 21 insertions(+)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 16a4ca1..ec9ef9e 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -963,4 +963,25
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 1ec9c02..873f624 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -725,7 +725,7 @@ static int edit_branch_description(cons
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bf8f911..ee64846 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -735,6 +735,12 @@ branch..
- move the comment in 5/5 into the commented code block
- resolve branch name for "HEAD" in 4/5
Nguyễn Thái Ngọc Duy (5):
config.txt: a few lines about branch..description
branch: delete branch description if it's empty
t4014: a few more tests on cover letter using branch description
for
Junio C Hamano writes:
> Greg Troxel writes:
>
>> I realize a README.foo file for N different systems could be clutter,
>> but having these checked in would provide the concise help that people
>> on any of those platforms need.
>
> Our Makefile documents knobs people on various platforms can t
Am 03.01.2013 10:50, schrieb Grégory Pakosz:
>>
>> IOW, if the command was something like
>>
>> git filter-branch ...filter options... -- v1.0 master ...
>>
>> and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be
>> deleted if the commit it points to goes away. But if the comm
Am 03.01.2013 08:03, schrieb Junio C Hamano:
> The intended use case is to "go beyond rerere". Given a history of
> this shape:
>
> o---o---o---I mainline
>/
> O---o---X---o---Atopic A
>\
> o---Y---o---o---B topic B
>
> Suppose in the original O we had a function "di
On 01/03/2013 08:03 AM, Junio C Hamano wrote:
> I'd like a datastore that maps a pair of commit object names to
> another object name, such that:
>
> * When looking at two commits A and B, efficiently query all data
>associated with a pair of commits where X is contained in
>the range A.
>
> IOW, if the command was something like
>
> git filter-branch ...filter options... -- v1.0 master ...
>
> and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be
> deleted if the commit it points to goes away. But if the commit did not
> go away, but was rewritten, then it is
Am 03.01.2013 00:19, schrieb Junio C Hamano:
> Grégory Pakosz writes:
>
>> So we have an annotated tag that points to a commit that is rewritten
>> to nothing as the result of the filtering. What should happen?
>
> If the user asked to filter that tag itself, it may make sense to
> remove it, ra
On Tue, Jan 01, 2013 at 02:24:46PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > So I think we need to update twoway_merge to recognize unmerged entries,
> > which gives us two options:
> >
> > 1. Reject the merge.
> >
> > 2. Throw away the current unmerged entry in favor of the "ne
On Wed, Jan 02, 2013 at 11:03:00PM -0800, Junio C Hamano wrote:
> I'd like a datastore that maps a pair of commit object names to
> another object name, such that:
>
> * When looking at two commits A and B, efficiently query all data
>associated with a pair of commits where X is contained i
51 matches
Mail list logo
