David Aguilar writes:
> How do we feel about this duplication?
> Should we make a common function in the git-sh-setup.sh,
> or is it okay to have a slightly modified version of this
> function in two places?
It probably is a good idea to have it in one place. That would also
solve the @@DIFF@@
Kevin Bracey writes:
> I agree that this is the controversial patch of the two. It's going to
> chuck away 3-4 years of what Git users are used to, albeit in favour
> of a decade of what Perforce users are used to. And it also makes it
> inconsistent with all the other mergetools (at least assumi
Am 3/6/2013 15:42, schrieb Uwe Kleine-König:
> On Wed, Mar 06, 2013 at 02:24:18PM +0100, Johannes Sixt wrote:
>> Am 3/6/2013 11:16, schrieb Uwe Kleine-König:
>>> ++<<< ours
>>> +ssize_t xread(int fd, void *buf, size_t count)
>>> +{
>>> + ssize_t ret, done = 0;
>>> +
On 07/03/2013 02:36, Junio C Hamano wrote:
Kevin Bracey writes:
Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.
Given that the ordering of th
These slightly improve the reading flow by making it obvious that a list
follows.
Signed-off-by: Lukas Fleischer
---
bundle.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bundle.c b/bundle.c
index 65db53b..8cd8b4f 100644
--- a/bundle.c
+++ b/bundle.c
@@ -183,8 +183
A more informative message for "complete" bundles was added in commit
8c3710fd. However, the prerequisites ref list is currently read *after*
we check if it equals zero, which means we never actually print the
newly introduced message.
Move the code that reads the prerequisites ref list before the
On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey wrote:
> +make_virtual_base() {
> + # Copied from git-merge-one-file.sh.
> + # This starts with $LOCAL, and uses git apply to
> + # remove lines that are not in $REMOTE.
> + cp -- "$LOCAL" "$BASE"
On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey wrote:
> Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
>
>p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"
>
> Commit 0a0ec7bd changed this to:
>
>p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED"
>
> to avoid the problem of b
git.kernel.org no longer uses gitweb but has switched to cgit.
Info about this can be found on: https://www.kernel.org/pelican.html or
simply by looking at http://git.kernel.org . This is change since
2013-03-01.
Signed-off-by: Fredrik Gustafsson
---
gitweb/README |3 ---
1 fil ändrad, 3 bo
On Wed, Mar 06, 2013 at 04:41:44PM -0800, Junio C Hamano wrote:
> > Or we could just pass them through. Looks like this was already fixed by
> > 8556646 (fetch --all: pass --tags/--no-tags through to each remote,
> > 2012-09-05), which is in v1.7.12.2 and higher.
>
> ;-) No wonder this looked so
Hi Junio,
The following changes since commit 7799588faa2a8071da8ef047c87f9a1520fb8903:
Merge git://github.com/git-l10n/git-po (2013-03-04 01:16:02 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to a7409dfbc1c0d7e0c62f704a
On Wed, Mar 06, 2013 at 01:50:46PM -0800, Junio C Hamano wrote:
> I think it is more like "I added bread and my wife added bread to
> our common shopping list" and our two-way "RCS merge" default is to
> collapse that case to "one loaf of bread on the shopping list". My
> impression has always be
Jeff King writes:
> On Wed, Mar 06, 2013 at 01:56:01PM -0800, Junio C Hamano wrote:
>
>> Cristian Tibirna writes:
>>
>> > Hello
>> >
>> > $ git --version
>> > git version 1.7.10.4
>> >
>> > $ git fetch origin --no-tags
>> > does what it says
>> >
>> > $ git fetch --all --no-tags
>> > still gets
Kevin Bracey writes:
> Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
> the incoming branch is now in the left-hand, blue triangle pane, and the
> current branch is in the right-hand, green circle pane.
Given that the ordering of the three variants has been the way it is
On Wed, Mar 06, 2013 at 01:56:01PM -0800, Junio C Hamano wrote:
> Cristian Tibirna writes:
>
> > Hello
> >
> > $ git --version
> > git version 1.7.10.4
> >
> > $ git fetch origin --no-tags
> > does what it says
> >
> > $ git fetch --all --no-tags
> > still gets all the tags from the remote.
> >
Jan Pešta writes:
> See http://www.open.collab.net/community/subversion/articles/merge-info.html
> Extract:
> The range r30430:30435 that was added to 1.5.x in this merge has a '*'
> suffix for 1.5.x\www.
> This '*' is the marker for a non-inheritable mergeinfo range.
> The '*' means that only th
Michael J Gruber writes:
> Well, even in the simple case one has to wonder: Why does the user
> invoke help for "co"? There are two very likely cases:
>
> A) User does not remember what "co" is aliased to.
> B) User wants to see the man page.
>
> If A is not the case then it's easy for the user t
Junio C Hamano writes:
> In other words, with the new world order, wouldn't a saner function
> signature be:
>
> static const char *read_and_strip_branch(const char **path);
Eh, discard an asterisk from there. "Given a string to name the
file, read it to find the branch name recorded in i
Two changes to the same piece of code that have greatly improved the behaviour
of P4Merge for me. Some of it may also be applicable to other mergetools.
I've put probably overly-long-winded explanations in the commit messages.
Comments welcome. In particular, I know almost nothing of sh, so I may
Stephen Bash writes:
> So what is the actual meaning of "Already up-to-date!"? Is it
> based on the tree, the reachable commits, or something more
> complicated?
The resulting tree of the merge happened to be the same as the
original tree (i.e. "git diff HEAD^ HEAD" is empty).
This happens qui
Antoine Pelisse writes:
> Add basic use cases and corner cases tests for
> "git diff -M --summary/stat".
>
> Signed-off-by: Antoine Pelisse
> ---
> list of fixes:
> - Test using diff instead of show
> (that is more consistent with commit message).
> - add extra spaces around paths
> - Use be
Hi all-
I have a branch history that looks like this:
--M-M-- master
\ / /
x feature
\ \
x-A- maint
In other words we had a new feature that was "so cool" that after testing on
master was back-ported to maint (luckily
Cristian Tibirna writes:
> Hello
>
> $ git --version
> git version 1.7.10.4
>
> $ git fetch origin --no-tags
> does what it says
>
> $ git fetch --all --no-tags
> still gets all the tags from the remote.
>
> Is this known?
Because --all (or --multiple) to iterate through all remotes
does not pas
Jeff King writes:
> I think Uwe's example shows that it _is_ useful. Yes, you no longer have
> the information about what happened through 1-14 (whether it was really
> there in the ancestor file, or whether it was simply added identically).
> But that information might or might not be relevant.
Hello
$ git --version
git version 1.7.10.4
$ git fetch origin --no-tags
does what it says
$ git fetch --all --no-tags
still gets all the tags from the remote.
Is this known?
Thanks.
--
Cristian Tibirna(1-418-) 656-2131 / 4340
Laval University - Quebec, CAN .
Add basic use cases and corner cases tests for
"git diff -M --summary/stat".
Signed-off-by: Antoine Pelisse
---
list of fixes:
- Test using diff instead of show
(that is more consistent with commit message).
- add extra spaces around paths
- Use better commit messages
- Moved to existing t40
See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was added to 1.5.x in this merge has a '*'
suffix for 1.5.x\www.
This '*' is the marker for a non-inheritable mergeinfo range.
The '*' means that only the path on which the mergeinfo is
Junio C Hamano writes:
> Jeff King writes:
>
>> But it would apply to the content that is outside
>> of the hunk marker; we have changed the concept of what is in the base
>> and what is in the conflict by shrinking the conflict to its smallest
>> size.
>
> Hmm, unless you mean by "base" somethi
Hello Junio,
On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > But it would apply to the content that is outside
> > of the hunk marker; we have changed the concept of what is in the base
> > and what is in the conflict by shrinking the conflict to its sma
Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.
This change makes use of P4Merge consistent with its built-in help, its
reference documentation, a
On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > But it would apply to the content that is outside
> > of the hunk marker; we have changed the concept of what is in the base
> > and what is in the conflict by shrinking the conflict to its smallest
> > siz
Jeff King writes:
> But it would apply to the content that is outside
> of the hunk marker; we have changed the concept of what is in the base
> and what is in the conflict by shrinking the conflict to its smallest
> size.
Hmm, unless you mean by "base" something entirely different from
"what wa
Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"
Commit 0a0ec7bd changed this to:
p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED"
to avoid the problem of being unable to save in some circumstances.
Unfortunately this appro
On Wed, Mar 06, 2013 at 12:40:48PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > then it will produce the output that Uwe expects. While it can be
> > misleading,...
>
> Misleading is one thing but in this case isn't it outright wrong?
>
> If you remove <<< ours ||| portion from the c
On Wed, Mar 06, 2013 at 09:36:42PM +0100, Uwe Kleine-König wrote:
> "zdiff3" is identical to ordinary diff3, only it allows more aggressive
> compaction than diff3. This way the displayed base isn't necessary
> technically correct, but still this mode might help resolving merge
> conflicts between
Jeff King writes:
> then it will produce the output that Uwe expects. While it can be
> misleading,...
Misleading is one thing but in this case isn't it outright wrong?
If you remove <<< ours ||| portion from the combined diff output,
I would expect that the hunk will apply to the base, but tha
"zdiff3" is identical to ordinary diff3, only it allows more aggressive
compaction than diff3. This way the displayed base isn't necessary
technically correct, but still this mode might help resolving merge
conflicts between two near identical additions.
Signed-off-by: Uwe Kleine-König
---
Hello,
On Wed, Mar 06, 2013 at 08:26:57PM +0100, Antoine Pelisse wrote:
> > however the difference isn't that easy to spot any more. I expected
> >
> > diff --cc file
> > index a07e697,5080129..000
> > --- a/file
> > +++ b/file
> > @@@ -12,7 -12,7 +12,12 @@@
>
> however the difference isn't that easy to spot any more. I expected
>
> diff --cc file
> index a07e697,5080129..000
> --- a/file
> +++ b/file
> @@@ -12,7 -12,7 +12,12 @@@
> 12
> 13
> 14
> ++<<< ours
> +
Nguyễn Thái Ngọc Duy writes:
> +static void wt_status_get_detached_from(struct wt_status_state *state)
> +{
> + struct grab_1st_switch_cbdata cb;
> + struct commit *commit;
> + unsigned char sha1[20];
> + char *ref = NULL;
> +
> + strbuf_init(&cb.buf, 0);
> + if (for_each
This is how I see what rebase should do:
The simple case for rebase starts from
P---Q---R---S master
\
A---B---C topic
Then "git checkout topic ; git rebase master" will change it to
P---Q---R---S master
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> wt-status.c | 52 +++-
> wt-status.h | 5 +++--
> 2 files changed, 34 insertions(+), 23 deletions(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index ef405d0..183aafe 1
> git checkout --conflict=diff3 file
That's somehow unrelated, but shouldn't we have a "conflict" option to
git-merge as we have for git-checkout ?
With something like this (pasted into gmail):
diff --git a/builtin/merge.c b/builtin/merge.c
index 7c8922c..edad742 100644
--- a/builtin/mer
On Mon, Feb 25, 2013 at 05:44:05PM +0100, Daniel Bratell wrote:
> I can phrase this in two ways and I'll start with the short way:
>
> Why does a merge of a git submodule use as merge-base the commit that was
> active in the merge-base of the parent repo, rather than the merge-base of
> the tw
Nguyễn Thái Ngọc Duy writes:
> remote.*.push is considered before push.default, but there's no
> mention about that, except a bit in the examples. The description
> of push.default does say something about this, but it would be easier
> to find out if it's described here.
>
> The first paragraph
Greg Price writes:
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index 388a225..f89d920 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -105,7 +105,9 @@ apply to the index. See EDITING PATCHES below.
> will never stage new files, but
Jeff King writes:
> On Tue, Mar 05, 2013 at 02:47:15PM -0800, Junio C Hamano wrote:
>
>> The primary change since the last round is that it pushes out only
>> annotated tags that are missing from the other side.
>
> Like you, I have mixed feelings on treating annotated tags separately. I
> don't
Jeff King writes:
> On Tue, Mar 05, 2013 at 02:47:16PM -0800, Junio C Hamano wrote:
>
>> clear_commit_marks(struct commit *, unsigned) only can clear flag
>> bits starting from a single commit; introduce an API to allow
>> feeding an array of commits, so that flag bits can be cleared from
>> comm
Hello,
Here comes another recipe for a different suggestion:
git init
echo 1 > file
git add file
git commit -m 'base'
git branch branch
seq 1 30 | grep -v 15 > file
git commit -m 'add 2-30 without 15' file
git checkout branch
On Wed, Mar 06, 2013 at 02:24:18PM +0100, Johannes Sixt wrote:
> Am 3/6/2013 11:16, schrieb Uwe Kleine-König:
> > ++<<< ours
> > +ssize_t xread(int fd, void *buf, size_t count)
> > +{
> > + ssize_t ret, done = 0;
> > +
> > +retry:
> > + ret = read(fd,
We discussed this before about adding configuration variables into
individual command man pages [1]. This may be a step towards
that. With this, I could add selected configuration variables to
git-push.txt, for example, with a simple patch:
-- 8< --
diff --git a/Documentation/git-push.txt b/Docume
Am 3/6/2013 11:16, schrieb Uwe Kleine-König:
> ++<<< ours
>+ssize_t xread(int fd, void *buf, size_t count)
>+{
>+ ssize_t ret, done = 0;
>+
>+retry:
>+ ret = read(fd, buf + done, count - done);
>+ if (ret < 0)
>
Jeff King venit, vidit, dixit 05.03.2013 18:38:
> On Tue, Mar 05, 2013 at 02:44:41PM +, Ævar Arnfjörð Bjarmason wrote:
>
>> Change the semantics of "git --help" to show the help for the
>> command is aliased to, instead of just saying:
>>
>> `git ' is aliased to `'
>>
>> E.g. if you have
remote.*.push is considered before push.default, but there's no
mention about that, except a bit in the examples. The description
of push.default does say something about this, but it would be easier
to find out if it's described here.
The first paragraph describing refspec format is moved down, s
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases? Is it detached because the user checks out a remote ref or a
tag (and which one)?
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Oops, the previous one did n
Since the previous round:
- reflog format change is dropped
- almost always show "HEAD detached from/at xxx" instead of
"currently not on any branch", where "xxx" is either a ref, or an
abbreviated sha-1
I wanted to introduce something like @{-1:to} that resolves the "to"
sha-1 in reflog,
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases? Is it detached because the user checks out a remote ref or a
tag (and which one)?
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/branch.c
When a remote ref or a tag is checked out, HEAD is automatically
detached. There is no user-friendly way to find out what ref is
checked out in this case. This patch digs in reflog for this
information and shows "HEAD detached from origin/master" or "HEAD
detached at v1.8.0" instead of "currently n
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wt-status.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 183aafe..6a3566b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1044,31 +1044,29 @@ void wt_status_get_s
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wt-status.c | 52 +++-
wt-status.h | 5 +++--
2 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index ef405d0..183aafe 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -
Since the previous round:
- reflog format change is dropped
- almost always show "HEAD detached from/at xxx" instead of
"currently not on any branch", where "xxx" is either a ref, or an
abbreviated sha-1
I wanted to introduce something like @{-1:to} that resolves the "to"
sha-1 in reflog,
Intro
-
In 'Subject:' characters are encoded in Q encoding, as per RFC 2047, e.g.
föö
becomes
=?UTF-8?q?f=C3=B6=C3=B6?=
. Long encoded lines must be wrapped to be no longer than 76 bytes.
Also RFC 2047, section 5 (3) says:
Each 'encoded-word' MUST represent an integral number
On Wed, 6 Mar 2013, Yves Blusseau wrote:
I have try with an old version of curl: 7.15.5 and with the latest in
development curl 7.29.1-DEV. But it seem that git-remote-http is compile
with the old one.
libcurl 7.15.5 is over 6 years old.
The support for "socks[*]://" prefixes in proxy names
Hello,
I think the following suggestion is sound. And it might even be easy to
implement but I don't know how rerere works, so I might be wrong here.
When applying a patch it's normal to hit a conflict. For me this just
happend:
$ git diff
diff --cc flash_otp_write.c
inde
2013/3/6 Jeff King :
> On Wed, Mar 06, 2013 at 10:21:42AM +0100, Yves Blusseau wrote:
>
>> > Try:
>> >
>> > git config --global http.proxy 'socks://yourhost:port'
>> >
>> > That will enable it for all git repositories on your machine. Git should
>> > also respect any environment variables that cu
On Wed, Mar 06, 2013 at 10:21:42AM +0100, Yves Blusseau wrote:
> > Try:
> >
> > git config --global http.proxy 'socks://yourhost:port'
> >
> > That will enable it for all git repositories on your machine. Git should
> > also respect any environment variables that curl handles (because we use
> >
2013/3/6 Jeff King :
> Try:
>
> git config --global http.proxy 'socks://yourhost:port'
>
> That will enable it for all git repositories on your machine. Git should
> also respect any environment variables that curl handles (because we use
> libcurl under the hood), if you prefer to set it up that
> Try:
>
> git config --global http.proxy 'socks://yourhost:port'
>
> That will enable it for all git repositories on your machine. Git should
> also respect any environment variables that curl handles (because we use
> libcurl under the hood), if you prefer to set it up that way. See "man
> curl
On Tue, Mar 05, 2013 at 11:13:12PM +0100, David Krmpotic wrote:
> Hi guys! Thank you for responses.. I haven't suspected that repos
> created via GitHub windows app would have union set by default :( have
> to ask them about it.. it seems wrong to me… Here are the defaults for
> a windows repo cre
On Tue, Mar 05, 2013 at 02:47:15PM -0800, Junio C Hamano wrote:
> The primary change since the last round is that it pushes out only
> annotated tags that are missing from the other side.
Like you, I have mixed feelings on treating annotated tags separately. I
don't feel like the previous discuss
On Tue, Mar 05, 2013 at 02:47:16PM -0800, Junio C Hamano wrote:
> clear_commit_marks(struct commit *, unsigned) only can clear flag
> bits starting from a single commit; introduce an API to allow
> feeding an array of commits, so that flag bits can be cleared from
> commits reachable from any of t
Hello Junio,
On Tue, Mar 05, 2013 at 08:13:50AM -0800, Junio C Hamano wrote:
> >> Support determining the binaries' installation path at runtime even if
> >> called without any path components (i.e. via search path).
> The default for any change is not to include it. Is there any
> reason why w
On Wed, Mar 06, 2013 at 09:12:30AM +0100, Yves Blusseau wrote:
> i have a socks proxy to access internet.
> I successed in configuring git (with GIT_PROXY_COMMAND) to use the
> socks proxy for GIT transport protocol.
> But how to use this socks proxy with git for HTTP(S) transport protocol ?
Try:
73 matches
Mail list logo
