* Re: Weird problem with git-submodule.sh
From: Phil Hord @ 2012-12-12 19:10 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: Junio C Hamano, Marc Branchaud, Git Mailing List
In-Reply-To: <50C4FD00.4010003@gmail.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
> It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to
> upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.
Dash has been the default '/bin/sh' for Ubuntu for quite a long time
now[1] in spite of repeated reports of compatibility problems[2].
Phil
[1] https://wiki.ubuntu.com/DashAsBinSh
[2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Brian J. Murrell @ 2012-12-12 18:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kevin, git
In-Reply-To: <7vvcc73yzh.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
On 12-12-12 01:29 PM, Junio C Hamano wrote:
>
> Here the end of the pre-context matches the end of the added lines,
> but it will produce worse result if you blindly apply the "shift the
> hunk up" trick:
Yeah. I would not think a blind shift would be appropriate. But I
wonder if diff can take whitespace hints about when to shift and when
not to.
It would still never be perfect but might be more accurate than it is
now. Can't imagine it would be any worse.
b.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Junio C Hamano @ 2012-12-12 18:29 UTC (permalink / raw)
To: Kevin; +Cc: git
In-Reply-To: <CAO54GHD3C2RKUvE5jK_XOCVbbDuE_c5xfe28rOL+DaE5anL-Wg@mail.gmail.com>
Kevin <ikke@ikke.info> writes:
> Regularly I notice that the diffs that are provided (through diff, or
> add -p) tend to disconnect changes that belong to each other and
> report lines being changed that are not changed.
>
> An example for this is:
>
> /**
> + * Default parent
> + *
> + * @var int
> + * @access protected
> + * @index
> + */
> + protected $defaultParent;
> +
> + /**
>
> I understand this is a valid view of what is changed, but not a very
> logical view from the point of the user.
>
> I wondered if there is a way to improve this, or would that have other
> consequences.
I think your example shows a case where the end of the pre-context
matches the end of the added text in the hunk, and it appears it may
produce a better result if you shift the hunk up. But I think that
works only half the time. Imagine:
@@ -K,L +M,N @@
}
+void new_function(void)
+{
+ printf("hello, world.\n");
+}
+
void existing_one(void)
{
printf("goodbye, world.\n");
Here the end of the pre-context matches the end of the added lines,
but it will produce worse result if you blindly apply the "shift the
hunk up" trick:
... what was before the } we saw in the precontext ...
+}
+
+void new_function(void)
+{
+ printf("hello, world.\n");
}
void existing_one(void)
So I think with s/Regularly/About half the time/, your observation
above is correct.
I think the reason you perceived this as "Regularly" is that you do
not notice nor appreciate it when things go right (half the time),
but you tend to notice and remember only when a wrong side happened
to have been picked (the other half).
^ permalink raw reply
* Re: [PATCH v7 0/3] submodule update: add --remote for submodule's upstream changes
From: Junio C Hamano @ 2012-12-12 18:19 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121212152437.GB5157@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> On Tue, Dec 11, 2012 at 09:42:48PM -0800, Junio C Hamano wrote:
>> What branch did you base this series on?
>
> Every version of this series has been based on v1.8.0.
Thanks.
There were quite a few changes to git-submodule.sh since then to
'master' and I had to either wiggle the patch or know which exact
one 1/3 needs to be applied to in order to allow 2/3 to apply (try
applying these three to 'master' yourself---you will likely to see
that 2/3 will stop with conflicts).
In any case, I ended up applying them by editing the patches, and I
should have a good copy in 'pu'. Please double check the result.
Thanks.
^ permalink raw reply
* Re: [PATCH] index-format.txt: be more liberal on what can represent invalid cache tree
From: Junio C Hamano @ 2012-12-12 18:14 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1355316276-7661-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> We have been writing -1 as "invalid" since day 1. On that same day we
> accept all negative entry counts as "invalid". So in theory all C Git
> versions out there would be happy to accept any negative numbers. JGit
> seems to do exactly the same.
I am of two minds here.
The existing code is being more lenient than specified when they
read stuff others wrote, but it still adheres to -1 when writing.
Allowing random implementations to write random negative values will
close the door for us to later update the specification to encode
more informatin about these invalid entries by using negative value
other than -1 here.
I am OK with a reword to say "negative means invalid, and writers
should write -1 for invalid entries", but without the latter half,
this change is not justified.
> diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt
> index 9d25b30..2028a49 100644
> --- a/Documentation/technical/index-format.txt
> +++ b/Documentation/technical/index-format.txt
> @@ -161,8 +161,8 @@ GIT index format
> this span of index as a tree.
>
> An entry can be in an invalidated state and is represented by having
> - -1 in the entry_count field. In this case, there is no object name
> - and the next entry starts immediately after the newline.
> + a negative number in the entry_count field. In this case, there is no
> + object name and the next entry starts immediately after the newline.
>
> The entries are written out in the top-down, depth-first order. The
> first entry represents the root level of the repository, followed by the
^ permalink raw reply
* Re: [PATCH] git(1): remove a defunct link to "list of authors"
From: Junio C Hamano @ 2012-12-12 18:06 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20121212122448.GA20057@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I find the ohloh one a little more informative than the GitHub graph. I
> couldn't find any others (Google Code does not seem to have one,
> kernel.org and other gitweb sites do not, and I can't think of anywhere
> else that hosts a mirror).
Then let's do this.
-- >8 --
Subject: git(1): show link to contributor summary page
We earlier removed a link to list of contributors that pointed to a
defunct page; let's use a working one from Ohloh.net to replace it
instead.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git c/Documentation/git.txt w/Documentation/git.txt
index e643683..25e2f3a 100644
--- c/Documentation/git.txt
+++ w/Documentation/git.txt
@@ -869,7 +869,10 @@ Authors
-------
Git was started by Linus Torvalds, and is currently maintained by Junio
C Hamano. Numerous contributions have come from the git mailing list
-<git@vger.kernel.org>. If you have a clone of git.git itself, the
+<git@vger.kernel.org>. http://www.ohloh.net/p/git/contributors/summary
+gives you a more complete list of contributors.
+
+If you have a clone of git.git itself, the
output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you
the authors for specific parts of the project.
^ permalink raw reply related
* Re: [PATCH 0/2] mailmap from blobs
From: Jeff King @ 2012-12-12 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhanr5f74.fsf@alter.siamese.dyndns.org>
On Wed, Dec 12, 2012 at 09:54:23AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I noticed recently that the GitHub contributions page for git.git did
> > not seem very accurate. The problem is that while it uses shortlog, it
> > does not respect .mailmap, because we do not have a working tree from
> > which to read the .mailmap.
> >
> > This series adds a config option analogous to mailmap.file, but which
> > reads from a blob in the repository (so the obvious thing to set it to
> > is "HEAD:.mailmap" in a bare repo, and probably "master:.mailmap" if you
> > frequently want to traverse while on unrelated branches). The obvious
> > alternative is to checkout a temporary file of .mailmap and point
> > mailmap.file at it, but this is a bit more convenient.
>
> Yeah, I think this is sane.
>
> Have you considered defaulting to read from HEAD:.mailmap even when
> this new configuration is not there if core.bare is set? I would
> imagine that it would be the most convenient and match people's
> expectations.
Yeah, I almost suggested that, but I figured it could wait for the
feature to prove itself in the real world before turning it on by
default. It _should_ be pretty harmless, though, so I don't mind turning
it on by default.
-Peff
^ permalink raw reply
* Re: [PATCH 5/5] log: Add --use-mailmap option
From: Junio C Hamano @ 2012-12-12 17:58 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git, Rich Midwinter
In-Reply-To: <CALWbr2xmRVS9m623yrxY88Ftaen_B8Tb2vd+VxhYV1ceAmbDSg@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> On Tue, Dec 11, 2012 at 11:21 PM, Antoine Pelisse <apelisse@gmail.com> wrote:
>> Add the --use-mailmap option to log commands. It allows
>> to display names from mailmap file when displaying logs,
>> whatever the format used.
>
> The question is which log commands actually ?
> Shouldn't we put the option in revision.c::handle_revision_opt instead ?
I was trying to avoid that to make it harder to trigger the
"feature" by mistake. The rewriting with mailmap is for human
consumption and when we replay the history (e.g. format-patch used
as input for am or rebase), we should never be applying it.
^ permalink raw reply
* Re: [PATCH 0/2] mailmap from blobs
From: Junio C Hamano @ 2012-12-12 17:54 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121212105822.GA15842@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I noticed recently that the GitHub contributions page for git.git did
> not seem very accurate. The problem is that while it uses shortlog, it
> does not respect .mailmap, because we do not have a working tree from
> which to read the .mailmap.
>
> This series adds a config option analogous to mailmap.file, but which
> reads from a blob in the repository (so the obvious thing to set it to
> is "HEAD:.mailmap" in a bare repo, and probably "master:.mailmap" if you
> frequently want to traverse while on unrelated branches). The obvious
> alternative is to checkout a temporary file of .mailmap and point
> mailmap.file at it, but this is a bit more convenient.
Yeah, I think this is sane.
Have you considered defaulting to read from HEAD:.mailmap even when
this new configuration is not there if core.bare is set? I would
imagine that it would be the most convenient and match people's
expectations.
^ permalink raw reply
* Re: git-prompt.sh vs leading white space in __git_ps1()::printf_format
From: Junio C Hamano @ 2012-12-12 17:50 UTC (permalink / raw)
To: Simon Oosthoek; +Cc: Piotr Krukowiecki, git
In-Reply-To: <20121212085507.GA32187@xs4all.nl>
Simon Oosthoek <s.oosthoek@xs4all.nl> writes:
> This removes most of the ambiguities :-)
> Ack from me!
OK, as this is a low-impact finishing touch for a new feature, I'll
fast-track this to 'master' before the final release.
Thanks.
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Junio C Hamano @ 2012-12-12 17:49 UTC (permalink / raw)
To: Jeff King
Cc: Eric S. Raymond, Sitaram Chamarty, Patrick Donnelly,
Nguyen Thai Ngoc Duy, Michael Haggerty, Felipe Contreras, git
In-Reply-To: <20121212063208.GA18322@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think there are really two separate use cases to consider:
>
> 1. Providing snippets of script to Git to get Turing-complete behavior
> for existing Git features. For example, selecting commits during a
> traversal (e.g., a better "log --grep"), formatting output (e.g., a
> better "log --format" or "for-each-ref --format").
>
> 2. Writing whole new git commands in a language that is quicker or
> easier to develop in than C.
>
> I think (1) is a good match for lua....
>
> But for (2), you are going to care a lot more about the language and its
> ecosystem (because you'll be interacting more with the world outside of
> git), and about having bindings to lots of different parts of git
> (because you'll want to do more interesting things than just examine a
> few data structures).
Good summary. We also need to realize that adding a native
subcommand written in C has become much easier over time as our
internal API has evolved and matured. These days, we still do a
whole new command in scripts (and we have whole commands still in
scripts) not because "quicker or easier to develop" (that is still
true for throw-away experiments) but primarily because that is
easier to modify and experiment over time until we find a solid
design.
Among the more important subcommands that are still scripts, I think
"add -i", "repack", "pull", "stash" and possibly "rebase" have
interfaces facing to both the end users and to the core part
solidified enough that they can now be ported to C. Others either
are not important enough or still have rooms to improve the
interfaces in either direction that it would still be better to
leave them in scripts (e.g. "bisect" with "<used-to-be, now-is> vs
<good, bad>" issue unsettled, "submodule" with "floating" issue
unsettled, etc.).
^ permalink raw reply
* Re: [PATCH v7 2/3] submodule update: add --remote for submodule's upstream changes
From: Phil Hord @ 2012-12-12 17:43 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Junio C Hamano, Heiko Voigt, Jeff King, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <64d109da03c521303ad87b8370bf09ab28a5c09f.1355251862.git.wking@tremily.us>
Thanks for looking after this.
On Tue, Dec 11, 2012 at 1:58 PM, W. Trevor King <wking@tremily.us> wrote:
> From: "W. Trevor King" <wking@tremily.us>
>
> The current `update` command incorporates the superproject's gitlinked
> SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
> options you use, it may checkout $sha1, rebase the $subsha1 onto
> $sha1, or merge $sha1 into $subsha1. This helps you keep up with
> changes in the upstream superproject.
>
> However, it's also useful to stay up to date with changes in the
> upstream subproject. Previous workflows for incorporating such
> changes include the ungainly:
>
> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> With this patch, all of the useful functionality for incorporating
> superproject changes can be reused to incorporate upstream subproject
> updates. When you specify --remote, the target $sha1 is replaced with
> a $sha1 of the submodule's origin/master tracking branch. If you want
> to merge a different tracking branch, you can configure the
> `submodule.<name>.branch` option in `.gitmodules`. You can override
> the `.gitmodules` configuration setting for a particular superproject
> by configuring the option in that superproject's default configuration
> (using the usual configuration hierarchy, e.g. `.git/config`,
> `~/.gitconfig`, etc.).
>
> Previous use of submodule.<name>.branch
> =======================================
>
> Because we're adding a new configuration option, it's a good idea to
> check if anyone else is already using the option. The foreach-pull
> example above was described by Ævar in
>
> commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
> Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Date: Fri May 21 16:10:10 2010 +0000
>
> git-submodule foreach: Add $toplevel variable
>
> Gerrit uses the same interpretation for the setting, but because
> Gerrit has direct access to the subproject repositories, it updates
> the superproject repositories automatically when a subproject changes.
> Gerrit also accepts the special value '.', which it expands into the
> superproject's branch name.
>
> Although the --remote functionality is using `submodule.<name>.branch`
> slightly differently, the effect is the same. The foreach-pull
> example uses the option to record the name of the local branch to
> checkout before pulls. The tracking branch to be pulled is recorded
> in `.git/modules/<name>/config`, which was initialized by the module
> clone during `submodule add` or `submodule init`. Because the branch
> name stored in `submodule.<name>.branch` was likely the same as the
> branch name used during the initial `submodule add`, the same branch
> will be pulled in each workflow.
>
> Implementation details
> ======================
>
> In order to ensure a current tracking branch state, `update --remote`
> fetches the submodule's remote repository before calculating the
> SHA-1. However, I didn't change the logic guarding the existing fetch:
>
> if test -z "$nofetch"
> then
> # Run fetch only if $sha1 isn't present or it
> # is not reachable from a ref.
> (clear_local_git_env; cd "$path" &&
> ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> test -z "$rev") || git-fetch)) ||
> die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
> fi
>
> There will not be a double-fetch, because the new $sha1 determined
> after the `--remote` triggered fetch should always exist in the
> repository. If it doesn't, it's because some racy process removed it
> from the submodule's repository and we *should* be re-fetching.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/config.txt | 7 ++++++-
> Documentation/git-submodule.txt | 25 ++++++++++++++++++++++++-
> Documentation/gitmodules.txt | 5 +++++
> git-submodule.sh | 22 +++++++++++++++++++++-
> t/t7406-submodule-update.sh | 31 +++++++++++++++++++++++++++++++
> 5 files changed, 87 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 11f320b..6f4663c 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1998,7 +1998,12 @@ submodule.<name>.update::
> for a submodule. These variables are initially populated
> by 'git submodule init'; edit them to override the
> URL and other values found in the `.gitmodules` file. See
> - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
> +
> +submodule.<name>.branch::
> + The remote branch name for a submodule, used by `git submodule
> + update --remote`. Set this option to override the value found in
> + the `.gitmodules` file. See linkgit:git-submodule[1] and
> + linkgit:gitmodules[5] for details.
>
> submodule.<name>.fetchRecurseSubmodules::
> This option can be used to control recursive fetching of this
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index b4683bb..72dd52f 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -13,7 +13,7 @@ SYNOPSIS
> [--reference <repository>] [--] <repository> [<path>]
> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] init [--] [<path>...]
> -'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
> +'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [--rebase]
> [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
> [commit] [--] [<path>...]
> @@ -236,6 +236,29 @@ OPTIONS
> (the default). This limit only applies to modified submodules. The
> size is always limited to 1 for added/deleted/typechanged submodules.
>
> +--remote::
> + This option is only valid for the update command. Instead of using
> + the superproject's recorded SHA-1 to update the submodule, use the
> + status of the submodule's remote tracking branch. The remote used
> + is branch's remote (`branch.<name>.remote`), defaulting to `origin`.
> + The remote branch used defaults to `master`, but the branch name may
> + be overridden by setting the `submodule.<name>.branch` option in
> + either `.gitmodules` or `.git/config` (with `.git/config` taking
> + precedence).
> ++
> +This works for any of the supported update procedures (`--checkout`,
> +`--rebase`, etc.). The only change is the source of the target SHA-1.
> +For example, `submodule update --remote --merge` will merge upstream
> +submodule changes into the submodules, while `submodule update
> +--merge` will merge superproject gitlink changes into the submodules.
> ++
> +In order to ensure a current tracking branch state, `update --remote`
> +fetches the submodule's remote repository before calculating the
> +SHA-1. This makes `submodule update --remote --merge` similar to
> +running `git pull` in the submodule. If you don't want to fetch (for
> +something closer to `git merge`), you should use `submodule update
> +--remote --no-fetch --merge`.
I assume the same can be said for 'submodue update --remote --rebase',
right? I wonder if this can be made merge/rebase-agnostic. Is it
still true if I word it like this?:
In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. If you don't want to fetch, you should use `submodule update
--remote --no-fetch`.
> +
> -N::
> --no-fetch::
> This option is only valid for the update command.
> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
> index 4effd78..4004fa6 100644
> --- a/Documentation/gitmodules.txt
> +++ b/Documentation/gitmodules.txt
> @@ -47,6 +47,11 @@ submodule.<name>.update::
> This config option is overridden if 'git submodule update' is given
> the '--merge', '--rebase' or '--checkout' options.
>
> +submodule.<name>.branch::
> + A remote branch name for tracking updates in the upstream submodule.
> + If the option is not specified, it defaults to 'master'. See the
> + `--remote` documentation in linkgit:git-submodule[1] for details.
> +
> submodule.<name>.fetchRecurseSubmodules::
> This option can be used to control recursive fetching of this
> submodule. If this option is also present in the submodules entry in
> diff --git a/git-submodule.sh b/git-submodule.sh
> index f969f28..1395079 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -8,7 +8,8 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
> USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
> or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
> or: $dashless [--quiet] init [--] [<path>...]
> - or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> + or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> +ges
I think there's an unintentionally added line here with "ges".
> or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
> or: $dashless [--quiet] foreach [--recursive] <command>
> or: $dashless [--quiet] sync [--] [<path>...]"
> @@ -26,6 +27,7 @@ cached=
> recursive=
> init=
> files=
> +remote=
> nofetch=
> update=
> prefix=
> @@ -535,6 +537,9 @@ cmd_update()
> -i|--init)
> init=1
> ;;
> + --remote)
> + remote=1
> + ;;
> -N|--no-fetch)
> nofetch=1
> ;;
> @@ -595,6 +600,7 @@ cmd_update()
> fi
> name=$(module_name "$sm_path") || exit
> url=$(git config submodule."$name".url)
> + branch=$(get_submodule_config "$name" branch master)
> if ! test -z "$update"
> then
> update_module=$update
> @@ -629,6 +635,20 @@ Maybe you want to use 'update --init'?")"
> die "$(eval_gettext "Unable to find current revision in submodule path '\$sm_path'")"
> fi
>
> + if test -n "$remote"
> + then
> + if test -z "$nofetch"
> + then
> + # Fetch remote before determining tracking $sha1
> + (clear_local_git_env; cd "$sm_path" && git-fetch) ||
You should 'git fetch $remote_name' here, and of course, initialize
remote_name before this. But how can we know the remote_name in the
first place? Is it safe to assume the submodule remote names will
match those in the superproject?
> + die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
> + fi
> + remote_name=$(get_default_remote)
This get_default_remote finds the remote for the remote-tracking
branch for HEAD in the superproject. It is possible that HEAD !=
$branch, so we have very few clues to go on here to get a more
reasonable answer, so I do not have any good suggestions to improve
this.
One option would be to find the remote given for
submodule."$branch".merge, but this would suppose there is some
remote-tracking branch configured in the submodule, and that is not
likely to be the case.
> + sha1=$(clear_local_git_env; cd "$sm_path" &&
> + git rev-parse --verify "${remote_name}/${branch}") ||
This does assume the submodule remote names will match those in the
superproject. Is this safe?
> + die "$(eval_gettext "Unable to find current ${remote_name}/${branch} revision in submodule path '\$sm_path'")"
> + fi
> +
> if test "$subsha1" != "$sha1" -o -n "$force"
> then
> subforce=$force
> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
> index 1542653..a567834 100755
> --- a/t/t7406-submodule-update.sh
> +++ b/t/t7406-submodule-update.sh
> @@ -135,6 +135,37 @@ test_expect_success 'submodule update --force forcibly checks out submodules' '
> )
> '
>
> +test_expect_success 'submodule update --remote should fetch upstream changes' '
> + (cd submodule &&
> + echo line4 >> file &&
> + git add file &&
> + test_tick &&
> + git commit -m "upstream line4"
> + ) &&
> + (cd super &&
> + git submodule update --remote --force submodule &&
> + cd submodule &&
> + test "$(git log -1 --oneline)" = "$(GIT_DIR=../../submodule/.git git log -1 --oneline)"
> + )
> +'
> +
> +test_expect_success 'local config should override .gitmodules branch' '
> + (cd submodule &&
> + git checkout -b test-branch &&
> + echo line5 >> file &&
> + git add file &&
> + test_tick &&
> + git commit -m "upstream line5" &&
> + git checkout master
> + ) &&
> + (cd super &&
> + git config submodule.submodule.branch test-branch &&
> + git submodule update --remote --force submodule &&
> + cd submodule &&
> + test "$(git log -1 --oneline)" = "$(GIT_DIR=../../submodule/.git git log -1 --oneline test-branch)"
> + )
> +'
> +
> test_expect_success 'submodule update --rebase staying on master' '
> (cd super/submodule &&
> git checkout master
> --
> 1.8.0
>
^ permalink raw reply
* FW: Git log --graph doesn't output color when redirected
From: Srb, Michal @ 2012-12-12 17:35 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <72BB37CB88C48F4B925365539F1EE46C182613A9@icexch-m3.ic.ac.uk>
Unlike --pretty-format, --graph doesn’t output colors when the git log output
is redirected.
Tested on Ubuntu 12.04 and msys on Windows 8.
Is there a setting somewhere in config to change this?
Thanks,
Michal
^ permalink raw reply
* RE: (bug?) Inconsistent workdir file timestamps after initial clone.
From: Pyeron, Jason J CTR (US) @ 2012-12-12 17:26 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <50C8BC71.8030204@web.de>
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
> -----Original Message-----
> From: Torsten Bögershausen
> Sent: Wednesday, December 12, 2012 12:19 PM
>
>
>
> On 11.12.12 23:30, Junio C Hamano wrote:
> > Marc Branchaud <marcnarc@xiplink.com> writes:
> >
> >> My point is that the initial checkout into an empty working
> directory should
> >> create all files with the same timestamp.
> >>
> >> Or, to be a bit more precise, whenever git-checkout *creates* files
> in the
> >> work dir, *all* the created files should have the *same* timestamp
> (i.e. the
> >> current time measured at the start of the checkout's execution, not
> some
> >> bizarro other time specified by some arcane heuristic).
> >
> > My knee-jerk reaction is that it is insane to do so, but what other
> > SCM does such a thing? Even "tar xf" wouldn't do that, I think.
> >
>
>
> ClearCase is doing such a thing.
>
> You need to check out a file to make it writable:
> "cleartool checkout main.c"
> [hack hack]
> If you after some hacking don't like your changes at all,
> you run
> "cleartool unco main.c" (Undo checkout)
> (In git we just use "git checkout")
>
> While in ClearCase the timestamp of your file jumps back to where
> it was before the checkout, it gets the current timestamp in git.
I do think that a user preference should decide if git uses metadata timestamps or current timestamp on file operations. I don’t think that the current time is proper as a default operation.
>
> One consequence is that ClearCase users may wish to use "ClearMake"
> rather then make.
>
> A better make (which records all timestamps somewhere) would be
> helpful.
That is why I always do "make clean" after a rollback. Do you really expect build managers to handle a bi-directional, with regards to time, SDLC? Build managers have worked hard to ensure incremental builds, it is silly to think that they should be re worked.
>
> >>> While not including files that can be rebuilt from the source may
> be
> >>> the ideal solution, I've seen projects hide rules to rebuild such a
> >>> "generated but needs special tools to build" and/or a "generated
> but
> >>> normal developers do not have any business rebuilding" file (in
> your
> >>> case, Makefile.in) in their Makefiles from the normal targets (like
> >>> "make all") for this exact reason, when they choose to distribute
> >>> such files by including in their commits.
> >>
> >> I prefer to use the third-party code as-is, without hacking it, to
> have
> >> smooth upgrades in the future.
> >
> > Then perhaps take the complaints to that third-party upstream, not
> > here?
> > --
> > To unsubscribe from this list: send the line "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: [PATCH v2] submodule: add 'deinit' command
From: Jens Lehmann @ 2012-12-12 17:22 UTC (permalink / raw)
To: Michael J Gruber
Cc: Junio C Hamano, Phil Hord, W. Trevor King, Git, Heiko Voigt,
Jeff King, Shawn Pearce, Nahor
In-Reply-To: <50C89DF3.20303@drmicha.warpmail.net>
Am 12.12.2012 16:08, schrieb Michael J Gruber:
> Jens Lehmann venit, vidit, dixit 04.12.2012 22:48:
>> With "git submodule init" the user is able to tell git he cares about one
>> or more submodules and wants to have it populated on the next call to "git
>> submodule update". But currently there is no easy way he could tell git he
>> does not care about a submodule anymore and wants to get rid of his local
>> work tree (except he knows a lot about submodule internals and removes the
>> "submodule.$name.url" setting from .git/config himself).
>>
>> Help those users by providing a 'deinit' command. This removes the whole
>> submodule.<name> section from .git/config either for the given
>> submodule(s) or for all those which have been initialized if none were
>> given. Complain only when for a submodule given on the command line the
>> url setting can't be found in .git/config.
>
> Whoaaa, so why not have "git rm" remove everything unless I specify a
> file to be removed?
Because "git add" doesn't add any file in that case either?
> I know I'm exaggerating a bit, but defaulting to "--all" for a
> destructive operation seems to be a bit harsh, especially when the
> command is targeted at "those" users that you mention.
All other submodule commands (except add, which only operates on a
single submodule to be) iterate over all submodules if none were
explicitly given on the command line. So I made deinit just behave
like all the others - and especially init - do. But if people really
are surprised by being consistent here I won't argue against adding
such a "--all" option, but currently I'm not convinced it is worth
it. Especially as I suspect the number of submodule users having
customized those in .git/config is not that high ...
^ permalink raw reply
* Re: (bug?) Inconsistent workdir file timestamps after initial clone.
From: Torsten Bögershausen @ 2012-12-12 17:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marc Branchaud, Git Mailing List
In-Reply-To: <7vr4mw6x3p.fsf@alter.siamese.dyndns.org>
On 11.12.12 23:30, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> My point is that the initial checkout into an empty working directory should
>> create all files with the same timestamp.
>>
>> Or, to be a bit more precise, whenever git-checkout *creates* files in the
>> work dir, *all* the created files should have the *same* timestamp (i.e. the
>> current time measured at the start of the checkout's execution, not some
>> bizarro other time specified by some arcane heuristic).
>
> My knee-jerk reaction is that it is insane to do so, but what other
> SCM does such a thing? Even "tar xf" wouldn't do that, I think.
>
ClearCase is doing such a thing.
You need to check out a file to make it writable:
"cleartool checkout main.c"
[hack hack]
If you after some hacking don't like your changes at all,
you run
"cleartool unco main.c" (Undo checkout)
(In git we just use "git checkout")
While in ClearCase the timestamp of your file jumps back to where
it was before the checkout, it gets the current timestamp in git.
One consequence is that ClearCase users may wish to use "ClearMake"
rather then make.
A better make (which records all timestamps somewhere) would be helpful.
>>> While not including files that can be rebuilt from the source may be
>>> the ideal solution, I've seen projects hide rules to rebuild such a
>>> "generated but needs special tools to build" and/or a "generated but
>>> normal developers do not have any business rebuilding" file (in your
>>> case, Makefile.in) in their Makefiles from the normal targets (like
>>> "make all") for this exact reason, when they choose to distribute
>>> such files by including in their commits.
>>
>> I prefer to use the third-party code as-is, without hacking it, to have
>> smooth upgrades in the future.
>
> Then perhaps take the complaints to that third-party upstream, not
> here?
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] fetch: ignore wildcarded refspecs that update local symbolic refs
From: Jay Soffian @ 2012-12-12 17:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O . Pearce, Stefan Zager
In-Reply-To: <7vmwxk6x0a.fsf_-_@alter.siamese.dyndns.org>
On Tue, Dec 11, 2012 at 5:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> In a repository cloned from somewhere else, you typically have a
> [...]
> * This time with minimal tests and an updated log message.
Sorry I haven't been reading the list much lately, so I don't know the
context which motivated this patch beyond the commit message. But,
this message is quite clear. So:
Acked-by: Jay Soffian
> diff --git a/remote.c b/remote.c
> index 04fd9ea..a72748c 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1370,6 +1370,16 @@ int branch_merge_matches(struct branch *branch,
> return refname_match(branch->merge[i]->src, refname, ref_fetch_rules);
> }
>
> +static int ignore_symref_update(const char *refname)
s/ignore_symref_update/is_existing_symref/ ?
j.
^ permalink raw reply
* [PATCH] Documentation/git: add missing info about --git-dir command-line option
From: Manlio Perillo @ 2012-12-12 17:04 UTC (permalink / raw)
To: git
The Documentation/git.txt file, in the GIT_DIR environment variable
section, did not mentioned that this value can also be set using the
--git-dir command line option.
---
Documentation/git.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index e643683..60db292 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -650,6 +650,7 @@ git so take care if using Cogito etc.
If the 'GIT_DIR' environment variable is set then it
specifies a path to use instead of the default `.git`
for the base of the repository.
+ The '--git-dir' command-line option also sets this value.
'GIT_WORK_TREE'::
Set the path to the working tree. The value will not be
--
1.8.0.1.347.gf94c325.dirty
^ permalink raw reply related
* Re: How to avoid the ^M induced by Meld and Git
From: Karl Brand @ 2012-12-12 16:17 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <50C8AC0A.1010306@drmicha.warpmail.net>
On 12/12/12 17:08, Michael J Gruber wrote:
> Karl Brand venit, vidit, dixit 12.12.2012 16:34:
>>
>>
>> On 12/12/12 15:57, Michael J Gruber wrote:
>>> Karl Brand venit, vidit, dixit 11.12.2012 13:33:
>>>> Esteemed Git users,
>>>>
>>>> What i do:
>>>>
>>>> 1. Create a script.r using Emacs/ESS.
>>>> 2. Make some modifications to script.r with the nice diff gui, Meld
>>>> 3. Commit these modifications using git commit -am "my message"
>>>> 4. Reopen script.r in Emacs/ESS to continue working.
>>>>
>>>> The lines added (&/edited ?) using Meld all end with ^M which i
>>>> certainly don't want. Lines not added/edited with Meld do NOT end with ^M.
>>>
>>> What happens if you leave out step 3? If the same happens then Meld is
>>> the culprit. (Unless you've set some special options, git does not
>>> modify your file on commit, so this can't be git related.)
>>>
>>
>> Leaving out step 3. results in exactly the same thing. Thus Git doesn't
>> appear to be responsible for the ^M's. Thanks a lot for your effort on
>> this and my apologies for not taking the care to dissect this more
>> carefully as you suggested. Over to the Meld mailing list...
>
> I didn't mean to shy you away ;)
Applying recent lessons form StackO'flow :P
>
> Could it be that there is a ^M very early in the file (or rather
> something else which isn't covered by dos2unix) so that Meld thinks it's
> DOS and inserts line endings as DOS? At least that's what vim would do.
>
If there is i don't find it using Emacs, but Emacs may only show what
dos2unix sees... Will post back the Meld insights (here's hoping!)
> In any case, Meld people over there should know (or get to know) that
> effect.
>
>>>> There are plenty of posts around about these being line endings used for
>>>> windows which can appear when working on a script under a *nix OS which
>>>> has previously been edited in a Windows OS. This is not the case here -
>>>> everything is taking place on Ubuntu 12.04.
>>>>
>>>> FWIW: the directory is being synced by dropbox; and in Meld, Preferences
>>>> > Encoding tab, "utf8" is entered in the text box.
>>>>
>>>> Current work around is running in a terminal: dos2unix /path/to/script.r
>>>> which strips the ^M's
>>>>
>>>> But this just shouldn't be necessary and I'd really appreciate the
>>>> reflections & advice on how to stop inducing these ^M's !
>>>>
>>>> With thanks,
>>>>
>>>> Karl
>>>>
>>>> (re)posted here as suggested off topic at SO:
>>>> http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m
>>>>
>>>
>>
--
Karl Brand
Dept of Cardiology and Dept of Bioinformatics
Erasmus MC
Dr Molewaterplein 50
3015 GE Rotterdam
T +31 (0)10 703 2460 |M +31 (0)642 777 268 |F +31 (0)10 704 4161
^ permalink raw reply
* Re: [PATCH] RFC Optionally handle symbolic links as copies
From: Robin Rosenberg @ 2012-12-12 16:15 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <50C89822.9050900@drmicha.warpmail.net>
----- Ursprungligt meddelande -----
> Robin Rosenberg venit, vidit, dixit 06.12.2012 02:23:
> >
> >
> > ----- Ursprungligt meddelande -----
> >> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> >>
> >>> If core.symlinks is set to copy then symbolic links in a git
> >>> repository
> >>> will be checked out as copies of the file it points to.
> >>
> >> That all sounds nice on surface when the primary thing you care
> >> about is to fetch and check out other people's code and extract it
> >> to the working tree, but how well would that work on the checkin
> >> side? What happens if I check out a symlink that points at a file
> >> (either in-tree or out-of-tree), make some changes that do not
> >> involve the symlink, and before I make the commit, an unrelated
> >> change is made to the file the symlink is pointing at?
> >>
> >>> - git status - when do we report a diff.
> >>> - After checkout we should probably not
> >>> - if the "linked" files change?
> >>
> >> Yeah, exactly.
> >>
> >>> - if a change in the copied directory chsnges
> >>
> >> That, too.
> >>
> >>> - if a file in the copied diretory is added/removed
> >>> - update, should we update the copied structure automatically
> >>> when the link target changes
> >
> > Some of the questions have proposals in the includes test script. A
> > little more dangerous than having real symlinks ofcourse, but
> > regardless
> > of what one does with or without copied symlinks one can make
> > mistakes
> > and I feel letting Git do the copying is way better than having
> > real
> > copies in the git repository. Another crappy scm which the users
> > are
> > converting from does this and it works. A difference to git is that
> > it (ok clearcase) makes all files read-only so there are fewer mays
> > of making mistakes with the copies.
> >
> >> I personally do not think this is worth it. It would be very
> >> useful
> >> on the export/checkout side, so it may make sense to add it to
> >> "git
> >> archive", though.
> >
> > It makes sense, but it does not solve the problem at hand.
> >
> > -- robin
> >
>
> Well, what is the problem at hand?
The problem is that I'm converting a repo from clearcase to git and
there are lots of symbolic links. Symbolic links in clearcase on
Windows is treated as file copy in snapshot views which means that
you get a copy of the linked file when you update the view. If the
link target changes you can update your view to refersh your copies.
> Your commit message begins in present tense as if it described the
> current state of git, when in fact it describes what the patch is
> about
> to achieve. This is confusing enough already,
You're right.
> I don't see any mention of the purpose, other than "content may be
> used", which would be served perfectly by a copy-on-link feature on
> the
> export side, as mentioned by Junio. Is git-archive|tar an option?
I want the copy on checkout. The intent is to change things and
then commit.
Perhaps I can convince people to let a script copy stuff instead.
-- robin
^ permalink raw reply
* Re: How to avoid the ^M induced by Meld and Git
From: Michael J Gruber @ 2012-12-12 16:08 UTC (permalink / raw)
To: Karl Brand; +Cc: git
In-Reply-To: <50C8A403.9050304@erasmusmc.nl>
Karl Brand venit, vidit, dixit 12.12.2012 16:34:
>
>
> On 12/12/12 15:57, Michael J Gruber wrote:
>> Karl Brand venit, vidit, dixit 11.12.2012 13:33:
>>> Esteemed Git users,
>>>
>>> What i do:
>>>
>>> 1. Create a script.r using Emacs/ESS.
>>> 2. Make some modifications to script.r with the nice diff gui, Meld
>>> 3. Commit these modifications using git commit -am "my message"
>>> 4. Reopen script.r in Emacs/ESS to continue working.
>>>
>>> The lines added (&/edited ?) using Meld all end with ^M which i
>>> certainly don't want. Lines not added/edited with Meld do NOT end with ^M.
>>
>> What happens if you leave out step 3? If the same happens then Meld is
>> the culprit. (Unless you've set some special options, git does not
>> modify your file on commit, so this can't be git related.)
>>
>
> Leaving out step 3. results in exactly the same thing. Thus Git doesn't
> appear to be responsible for the ^M's. Thanks a lot for your effort on
> this and my apologies for not taking the care to dissect this more
> carefully as you suggested. Over to the Meld mailing list...
I didn't mean to shy you away ;)
Could it be that there is a ^M very early in the file (or rather
something else which isn't covered by dos2unix) so that Meld thinks it's
DOS and inserts line endings as DOS? At least that's what vim would do.
In any case, Meld people over there should know (or get to know) that
effect.
>>> There are plenty of posts around about these being line endings used for
>>> windows which can appear when working on a script under a *nix OS which
>>> has previously been edited in a Windows OS. This is not the case here -
>>> everything is taking place on Ubuntu 12.04.
>>>
>>> FWIW: the directory is being synced by dropbox; and in Meld, Preferences
>>> > Encoding tab, "utf8" is entered in the text box.
>>>
>>> Current work around is running in a terminal: dos2unix /path/to/script.r
>>> which strips the ^M's
>>>
>>> But this just shouldn't be necessary and I'd really appreciate the
>>> reflections & advice on how to stop inducing these ^M's !
>>>
>>> With thanks,
>>>
>>> Karl
>>>
>>> (re)posted here as suggested off topic at SO:
>>> http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m
>>>
>>
>
^ permalink raw reply
* Re: (bug?) Inconsistent workdir file timestamps after initial clone.
From: Marc Branchaud @ 2012-12-12 15:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vr4mw6x3p.fsf@alter.siamese.dyndns.org>
On 12-12-11 05:30 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> My point is that the initial checkout into an empty working directory should
>> create all files with the same timestamp.
>>
>> Or, to be a bit more precise, whenever git-checkout *creates* files in the
>> work dir, *all* the created files should have the *same* timestamp (i.e. the
>> current time measured at the start of the checkout's execution, not some
>> bizarro other time specified by some arcane heuristic).
>
> My knee-jerk reaction is that it is insane to do so, but what other
> SCM does such a thing?
I'm lucky enough to just care about git these days.
> Even "tar xf" wouldn't do that, I think.
"tar xf" uses the timestamps that are stored in the tar file. I see this as
an argument against git's exact-current-time-per-file approach: even the tar
guys understand that it's insane.
>>> While not including files that can be rebuilt from the source may be
>>> the ideal solution, I've seen projects hide rules to rebuild such a
>>> "generated but needs special tools to build" and/or a "generated but
>>> normal developers do not have any business rebuilding" file (in your
>>> case, Makefile.in) in their Makefiles from the normal targets (like
>>> "make all") for this exact reason, when they choose to distribute
>>> such files by including in their commits.
>>
>> I prefer to use the third-party code as-is, without hacking it, to have
>> smooth upgrades in the future.
>
> Then perhaps take the complaints to that third-party upstream, not
> here?
Well, I thought that while I wait for some dozen-or-so projects to accept
changes to their builds, it might be nice for git to solve this problem for
me. It is, after all, an effect of the way git operates.
M.
^ permalink raw reply
* Re: How to avoid the ^M induced by Meld and Git
From: Karl Brand @ 2012-12-12 15:34 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <50C89B68.8090309@drmicha.warpmail.net>
On 12/12/12 15:57, Michael J Gruber wrote:
> Karl Brand venit, vidit, dixit 11.12.2012 13:33:
>> Esteemed Git users,
>>
>> What i do:
>>
>> 1. Create a script.r using Emacs/ESS.
>> 2. Make some modifications to script.r with the nice diff gui, Meld
>> 3. Commit these modifications using git commit -am "my message"
>> 4. Reopen script.r in Emacs/ESS to continue working.
>>
>> The lines added (&/edited ?) using Meld all end with ^M which i
>> certainly don't want. Lines not added/edited with Meld do NOT end with ^M.
>
> What happens if you leave out step 3? If the same happens then Meld is
> the culprit. (Unless you've set some special options, git does not
> modify your file on commit, so this can't be git related.)
>
Leaving out step 3. results in exactly the same thing. Thus Git doesn't
appear to be responsible for the ^M's. Thanks a lot for your effort on
this and my apologies for not taking the care to dissect this more
carefully as you suggested. Over to the Meld mailing list...
>> There are plenty of posts around about these being line endings used for
>> windows which can appear when working on a script under a *nix OS which
>> has previously been edited in a Windows OS. This is not the case here -
>> everything is taking place on Ubuntu 12.04.
>>
>> FWIW: the directory is being synced by dropbox; and in Meld, Preferences
>> > Encoding tab, "utf8" is entered in the text box.
>>
>> Current work around is running in a terminal: dos2unix /path/to/script.r
>> which strips the ^M's
>>
>> But this just shouldn't be necessary and I'd really appreciate the
>> reflections & advice on how to stop inducing these ^M's !
>>
>> With thanks,
>>
>> Karl
>>
>> (re)posted here as suggested off topic at SO:
>> http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m
>>
>
--
Karl Brand
Dept of Cardiology and Dept of Bioinformatics
Erasmus MC
Dr Molewaterplein 50
3015 GE Rotterdam
T +31 (0)10 703 2460 |M +31 (0)642 777 268 |F +31 (0)10 704 4161
^ permalink raw reply
* Fwd: possible Improving diff algoritm
From: Kevin @ 2012-12-12 15:03 UTC (permalink / raw)
To: git
In-Reply-To: <CAO54GHC4AXQO1MbU2qXMdcDO5mtUFhrXfXND5evc93kQhNfCrw@mail.gmail.com>
Regularly I notice that the diffs that are provided (through diff, or
add -p) tend to disconnect changes that belong to each other and
report lines being changed that are not changed.
An example for this is:
/**
+ * Default parent
+ *
+ * @var int
+ * @access protected
+ * @index
+ */
+ protected $defaultParent;
+
+ /**
I understand this is a valid view of what is changed, but not a very
logical view from the point of the user.
I wondered if there is a way to improve this, or would that have other
consequences.
^ permalink raw reply
* Re: [PATCH v7 0/3] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-12 15:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <7vtxrr6d2f.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Tue, Dec 11, 2012 at 09:42:48PM -0800, Junio C Hamano wrote:
> What branch did you base this series on?
Every version of this series has been based on v1.8.0.
> The preimage of git-submodule.sh in [2/3] does not seem to match
> anything I have (I could wiggle the patch, but in general I would
> rather prefer not having to).
From patch 1/3:
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..f969f28 100755
And from patch 2/3:
diff --git a/git-submodule.sh b/git-submodule.sh
index f969f28..1395079 100755
ab6b110 is in v1.8.0:
$ git ls-tree v1.8.0 git-submodule.sh
100755 blob ab6b1107b6090494f192f361471ed5748ffa7dc1 git-submodule.sh
I can reroll if necessary, but I'm not sure what I've done wrong…
Cheers,
Trevor
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox