Re: [PATCH 3/3] remote: introduce and fill branch-pushremote
On Sun, Jan 12, 2014 at 10:41:06PM +0530, Ramkumar Ramachandra wrote:
When a caller uses branch_get() to retrieve a struct branch, they get
the per-branch remote name and a pointer to the remote struct. However,
they have no way of knowing about the per-branch pushremote from this
interface. So, let's expose that information via fields similar to
remote and remote_name; pushremote and pushremote_name.
Makes sense. This is similar to what I posted before, but stops short of
setting branch-pushremote based on default.pushremote. I think that's
a good thing. Your patch matches branch-remote better, and the logic
for doing that fallback should probably stay outside of the struct
branch construct.
All 3 patches look like sane building blocks to me.
One comment on this hunk, though:
} else if (!strcmp(subkey, .pushremote)) {
+ if (git_config_string(branch-pushremote_name, key,
value))
+ return -1;
if (branch == current_branch)
- if (git_config_string(pushremote_name, key,
value))
- return -1;
+ pushremote_name = branch-pushremote_name;
In this code (both before and after your patch), pushremote_name does
double-duty for storing both remote.pushdefault, and the current
branch's branch.*.pushremote. I introduced an extra variable in my
version of the patch to store remote.pushdefault directly, and turned
pushremote_name into an alias (either to the current branch config, or
to the global config).
I did that for two reasons, one minor and one that I think will come up
further in the topic:
1. After your patch pushremote_name sometimes owns its memory (if
allocated for remote.pushdefault), and sometimes not (if an alias to
branch.*.pushremote). This isn't a problem in the current code,
because we never actually free() the string, meaning that if you
set push.default twice, we leak. But that probably does not matter
too much, and we have many such minor leaks of global config.
2. If the current branch has a branch.*.pushremote set, but we want to
know where a _different_ branch would be pushed, we have no way to
access remote.pushdefault (it gets overwritten in the hunk above).
@{upstream} does not have this problem, because it is _only_
defined if branch.*.remote is set. There is no such thing as
defaulting to a remote.default (or origin) there, and we never
need to look at default_remote_name.
For @{publish}, though, I think we will want that default. The
common config will be to simply set remote.pushdefault, rather
than setting up branch.*.pushremote for each branch, and we would
want @{publish} to handle that properly.
So I think your patch is OK as-is, as the problem in (2) does not show
up until later in the series. But I suspect you will need to do
something to address it (and I think it is fine as a patch that comes
later to do that refactoring).
-Peff
--
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
Re: [PATCH 3/3] remote: introduce and fill branch-pushremote
Jeff King wrote:
2. If the current branch has a branch.*.pushremote set, but we want to
know where a _different_ branch would be pushed, we have no way to
access remote.pushdefault (it gets overwritten in the hunk above).
@{upstream} does not have this problem, because it is _only_
defined if branch.*.remote is set. There is no such thing as
defaulting to a remote.default (or origin) there, and we never
need to look at default_remote_name.
For @{publish}, though, I think we will want that default. The
common config will be to simply set remote.pushdefault, rather
than setting up branch.*.pushremote for each branch, and we would
want @{publish} to handle that properly.
Not sure I understand what the problem is. Let's say we have two
branches: master, and side with remote.pushdefault = ram,
branch.*.remote = origin, and branch.side.pushremote = peff. Now, when
I query master's pushremote, I get ram and when I query side's
pushremote, I get peff; all the logic for falling-back from
branch.*.pushremote to remote.pushdefault to branch.*.remote is in
branch_get(), so I need to do nothing extra on the caller-side. From
the caller's perspective, why does it matter if the pushremote of a
particular branch is due to branch.*.pushremote or remote.pushdefault?
--
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
Re: [PATCH] git-p4: Do not include diff in spec file when just preparing p4
Hello, On Sun, Jan 12, 2014 at 05:29:46PM -0500, Pete Wyckoff wrote: Thanks for the patch, but I'm curious how you'd like this to work. I never use the option myself. As it is, --prepare-p4-only generates a file in /tmp/ that has exactly the contents you'd see in the editor during git p4 submit. It includes the diff of the change, presumably to help with writing the description. Yes, I believe it makes sense to display the diff in this case, as we can remove it later programmatically. Now you can't actually feed this file directly to p4 submit without deleting the diff. That's the part you don't like? Yes, I do not use that for submitting, but for shelving. I can run git p4 submit --prepare-p4-only followed by p4 shelve -i /tmp/... and perforce will shelve the corresponding change. Removing the diff could be done externally, however git-p4 itself tells the user it can submit using the generated file, which is not the case if we keep the diff in it. Cheers, Maxime Coste. -- 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
git-p4: exception when cloning a perforce repository
Hi !
I am trying to clone a perforce repository via git and I am having the
following backtrace :
{14:20}~/projects/:master ✗ ➭ git p4 clone //depot/@all .
Importing revision …
[...]
Importing revision 59702 (45%)Traceback (most recent call last):
File /opt/git/libexec/git-core/git-p4, line 3287, in module
main()
File /opt/git/libexec/git-core/git-p4, line 3281, in main
if not cmd.run(args):
File /opt/git/libexec/git-core/git-p4, line 3155, in run
if not P4Sync.run(self, depotPaths):
File /opt/git/libexec/git-core/git-p4, line 3008, in run
self.importChanges(changes)
File /opt/git/libexec/git-core/git-p4, line 2680, in importChanges
self.initialParent)
File /opt/git/libexec/git-core/git-p4, line 2304, in commit
self.streamP4Files(new_files)
File /opt/git/libexec/git-core/git-p4, line 2218, in streamP4Files
cb=streamP4FilesCbSelf)
File /opt/git/libexec/git-core/git-p4, line 482, in p4CmdList
cb(entry)
File /opt/git/libexec/git-core/git-p4, line 2212, in streamP4FilesCbSelf
self.streamP4FilesCb(entry)
File /opt/git/libexec/git-core/git-p4, line 2167, in streamP4FilesCb
self.streamOneP4File(self.stream_file, self.stream_contents)
File /opt/git/libexec/git-core/git-p4, line 2078, in streamOneP4File
if data[-1] == '\n':
IndexError: string index out of range
git —version: git version 1.8.5.2.309.ga25014b [last commit from master from
github.com/git/git]
os : ubuntu 13.10
Any ideas ? :)
Best regards,
Damien--
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
Submodule relative URL problems
Hi All,
I am currently working on a project, call it A, which contains several
sub-projects B, C, D. The B, C, D are actually experimental input and outputs
for simulation runs, which I need to keep track of the daily changes. Most of
these calculations are done on workstation, but I do need to occasionally clone
the repositories to other machines, and then push the updates back.
I version track B, C and D with independent git repositories, and
organisationally it makes sense for them to be subdirectories of A. I would
like to version control the overall project A, with B, C, D as submodules.
This is easily done on the main workstation (I will call it W1), with:
cd A
git init
for ii in B C D ; do
git submodule ./${ii}/.git
done
git add .
git commit
Repository A/.git on W1 does not have an origin. All seems to work fine with
this step up on W1.
HOWEVER, problem starts to appear when I attempted to clone the overall
repository A to another workstation W2:
git clone W1:path to A on W1/.git path to A on W2
cd path to A on W2
git submodule init
git submodule update
git then produces an error indicating that:
W1:path to A on W1/.git/B/.git
is not a valid repository (i.e. directory not found)
The extra .git has been inserted in the URL to submodule repository B, C, and D.
This can be solved by changing the .gitmodules file, replacing ./B/.git to
../B/.git, and then git submodule sync on W2.
However, this is far from being an optimal solution, because if .gitmodules on
W1 is updated accordingly, then the submodule repository for B would point to
path to A on W1/../B/.git
which will be incorrect. I could in principle define the URL for the submodule
repositories as absolute paths, but keeping them relative to A has many
advantages, such as I will be able to move A around, without effecting the main
repositories on W1 in anyway, and I can rsync them to another disk for backup
etc.
I would be very grateful if someone can offer me an solution to my problem.
Many thanks in advance!
Lianheng
Lianheng TongTel: +44 79 1758 3822
Room S4.02, Strand Building Fax: +44 20 7848 2420
Department of Physics lianheng.t...@kcl.ac.uk
Kings College London
Strand, London WC2R 2LS, U.K.
--
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
Re: [PATCH 2/6] read-cache: new extension to mark what file is watched
Hi,
Nguyễn Thái Ngọc Duy wrote:
If an entry is watched, git lets an external program decide if the
entry is modified or not. It's more like --assume-unchanged, but
designed to be controlled by machine.
We are running out of on-disk ce_flags, so instead of extending
on-disk entry format again, watched flags are in-core only and
stored as extension instead.
Makes sense.
Care to add a brief description of the on-disk format for
Documetnation/technical/index-format.txt as well?
[...]
--- a/cache.h
+++ b/cache.h
@@ -168,6 +168,7 @@ struct cache_entry {
/* used to temporarily mark paths matched by pathspecs */
#define CE_MATCHED (1 26)
+#define CE_WATCHED (1 27)
Nit: I'd add a blank line before the definition of CE_WATCHED to make
it clear that the comment doesn't apply to it.
Maybe it belongs with one of the groups before (e.g., UNPACKED +
NEW_SKIP_WORKTREE). I dunno.
--- a/read-cache.c
+++ b/read-cache.c
[...]
@@ -1289,6 +1290,19 @@ static int verify_hdr(struct cache_header *hdr,
return 0;
}
+static void read_watch_extension(struct index_state *istate, uint8_t *data,
+ unsigned long sz)
+{
+ int i;
+ if ((istate-cache_nr + 7) / 8 != sz) {
+ error(invalid 'WATC' extension);
+ return;
+ }
+ for (i = 0; i istate-cache_nr; i++)
+ if (data[i / 8] (1 (i % 8)))
+ istate-cache[i]-ce_flags |= CE_WATCHED;
+}
So the WATC section has one bit per index entry, encoding whether that
entry is WATCHED. Makes sense.
Do I understand correctly that this patch just takes care of the
bookkeeping for the CE_WATCHED bit and the actual semantics will
come in a later patch?
Thanks,
Jonathan
--
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
Re: [PATCH/RFC] Introduce git submodule add|update --attach
Francesco Pretto cez...@gmail.com writes: Thanks for the comments, my replies below. Before, a couple of general questions: - I'm also writing some tests, should I commit them together with the feature patch? - to determine the attached/detached state I did this: head_detached= if test $(rev-parse --abbrev-ref HEAD) = HEAD then head_detached=true fi Use git symbolic-ref HEAD to read off of it. -- 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
Hello!
Hello! I looked through your profile and decided to write you a message to inform you that i am interested in knowing more about you please you can contact me true my email so that i can tell you all about me ok Regards Miss. khadymo...@yahoo.com -- 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
Re: [PATCH] Create HTML for technical/http-protocol.txt
Thomas Ackermann th.ac...@arcor.de writes: - Add to Documentation/Makefile - Start every TODO with a new line - Fix indentation error Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/Makefile| 1 + Documentation/technical/http-protocol.txt | 3 +-- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 36c58fc..b4a4c82 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -70,6 +70,7 @@ TECH_DOCS += technical/racy-git TECH_DOCS += technical/send-pack-pipeline TECH_DOCS += technical/shallow TECH_DOCS += technical/trivial-merge +TECH_DOCS += technical/http-protocol The output from ls Documentation/technical/[b-z]*.txt tells me that this patch makes the TECH_DOCS cover everything (in other words, this is not I was intereted in http-protocol.txt; I did not bother checking if there are others that are not formatted.). Which is good, but that is something you could have said at the very beginning as the motivation (which cannot be read from the patch) before going into details of what you did (which can be read in the patch). Also let's keep them in order and move the new line before the index-format, as h comes before i. SP_ARTICLES += $(TECH_DOCS) SP_ARTICLES += technical/api-index diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index d21d77d..c64a5e9 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -332,6 +332,7 @@ server advertises capability allow-tip-sha1-in-want. have_list = *PKT-LINE(have SP id LF) TODO: Document this further. + TODO: Don't use uppercase for variable names below. The Negotiation Algorithm @@ -376,10 +377,8 @@ The computation to select the minimal pack proceeds as follows Commands MUST appear in the following order, if they appear at all in the request stream: - * want * have - The stream is terminated by a pkt-line flush (). A single want or have command MUST have one hex formatted The resulting _source_ file read as txt becomes somewhat harder to read with these changes. Admittedly, it is mostly because the original text was meant to be easy to read in TEXT, not to be formatted via AsciiDoc into HTML. We can see that in many places in the formatted output with your patch. For example: - Strings like 200 OK, 304 Not Modified, HEAD are italicized (Discovering References section); GET request is shown as Roman body text. I think in our documentation it is customery to typeset these as-is things in monospaced. - dumb server reply:, smart server reply: (Smart Clients section) are shown in monospace just like the actual protocol message examples that follow them, but we would most likely want to see them as part of the body text. - As all the descriptions of steps in the Negotiation Algorithm are indented, the AsciiDoc formatted result becomes just a series of fixed-font blocks around there. So,... I think this patch may be a good first step, but it needs to be followed by another that cleans up the mark-up in order for the resulting HTML to be truly usable. Thanks. -- 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
Re: [PATCH 3/3] remote: introduce and fill branch-pushremote
On Mon, Jan 13, 2014 at 04:52:52PM +0530, Ramkumar Ramachandra wrote:
Not sure I understand what the problem is. Let's say we have two
branches: master, and side with remote.pushdefault = ram,
branch.*.remote = origin, and branch.side.pushremote = peff. Now, when
I query master's pushremote, I get ram and when I query side's
pushremote, I get peff; all the logic for falling-back from
branch.*.pushremote to remote.pushdefault to branch.*.remote is in
branch_get(), so I need to do nothing extra on the caller-side. From
the caller's perspective, why does it matter if the pushremote of a
particular branch is due to branch.*.pushremote or remote.pushdefault?
Imagine your HEAD is at side. What should master@{publish} produce?
I would argue ram/master. Where does ram come from in your code?
It does not matter for actually pushing, because to do a non-default
push, you must always specify a remote. But @{publish} will ask the
question even if I am on 'side' now, what would happen if I were to
default-push on 'master'?.
-Peff
--
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
Re: Tight submodule bindings
Thanks for the writeup, comments below. Am 12.01.2014 02:08, schrieb W. Trevor King: Gitlinked commit hash - The submodule model revolves around links to commits (“gitlinks”): $ git ls-tree HEAD 100644 blob 189fc359d3dc1ed5019b9834b93f0dfb49c5851f.gitmodules 16 commit fbfa124c29362f180026bf0074630e8bd0ff4550 submod These are effectively switchable trees. The tree referenced by commit fbfa124 is 492781c: $ (cd submod/ git cat-file commit fbfa124) tree 492781c581d4dec380a61ef5ec69a104de448a74 … If you init the submodule, subsequent checkouts will check out that tree, just like 'git checkout' would do if you'd had a superproject tree like: $ git ls-tree HEAD 100644 blob 189fc359d3dc1ed5019b9834b93f0dfb49c5851f.gitmodules 04 tree 492781c581d4dec380a61ef5ec69a104de448a74submod For folks who treat the submodule as a black box (and do no local development), switchable trees are all they care about. They can easily checkout (or not, with deinit), the submodule tree at a gitlinked hash, and everything is nice and reproducible. The fact that 'submod' is stored as a commit object and not a tree, is just a convenient marker for optional init/deinit/remote-update-integration functionality. But there are users (like me) who do not treat submodules as black boxes and nonetheless do development in them with update set to checkout (after creating a feature branch of course ;-). Additional metadata, the initial checkout, and syncing down --- However, folks who do local submodule development will care about which submodule commit is responsible for that tree, because that's going to be the base of their local development. They also care about additional out-of-tree information, including the branch that commit is on. For already-initialized submodules, there are existing places in the submodule config to store this configuration: 1. HEAD for the checked-out branch, 2. branch.name.remote → remote.name.url for the upstream subproject URL, 4. branch.name.rebase (or pull.rebase) to prefer rebase over merge for integration, 5. … You need somewhere in-tree to store this destined-to-be-out-of-tree information, so that superproject developers that have not yet initialized the submodule will know what values are suggested by the superproject maintainers. That's where .gitmodules comes in, because storing all of this fairly static, locally overridable information in the gitlink itself would be nonsensical (said Linus in 2007 [1]). When you checkout a submodule for the first time, Git should take the default information from .gitmodules and file it away in the submodule's appropriate out-of-tree config locations. I disagree, that only makes sense for the URL setting (and this currently only happens with the update setting, which I intend to change). Everything else should be taken from .gitmodules unless the user wants to override it. The only setting I'm not so sure about is the local branch setting, as that might have to propagate into the submodule. The out-of-tree data listed above should be stored in: 1. submodule.name.local-branch 2. submodule.name.url 4. submodule.name.update 5. … Once you have an in-tree way to specify defaults for this out-of-tree information, you're going to have developers like me that just want to stick with the defaults, following them through changes. That means you'd like to have the “copy .gitmodules defaults into your submodule's config” functionality that usually happens on the initial submodule checkout happen on *every superproject-initiated checkout*. You don't need to copy it every time when you simply use the .gitmodules file as fallback, no? In fact, I think life is easier for everyone if this is the default, and we add a new option (submodule.name.sync = false) that says “don't overwrite optional settings in my submodule's out-of-tree config on checkout” for for folks who want to opt out. Don't worry, this is not going to clobber people, because we'll be syncing the other way too. Yet another flag to make peoples life easier? I don't think so ;-) Syncing up -- In the previous section I explained how data should flow from .gitmodules into out-of-tree configs. What about the other direction? We currently let folks handle this by hand, but I'd prefer a tighter integration between the submodule config and the superproject tree to avoid losing work. That means changes to tracked submodule status (checked-out hash, checked-out branch, upstream URL, upstream branch, default integration strategy, …) should trigger dirty-tree status just like uncommitted changes to in-tree files. 'git add' (or stash) on the dirty submodule would store changed commit hashes in the index, pull changed out-of-tree configs back into the in-tree .gitmodules, and add the new
Re: Submodule relative URL problems
Hi, Lianheng Tong wrote: git clone W1:path to A on W1/.git path to A on W2 Interesting. Thoughts: * More typical usage is to clone from a bare repository (A.git), which wouldn't have this problem. But I think your case is worth supporting, too. * What would you think of putting symlinks in A's .git directory? cd A/.git ln -s ../B ../C ../D . * Perhaps as a special case when the superproject is foo/.git, git should treat relative submodule paths as relative to foo/ instead of relative to foo/.git/. I think that would take care of your case without breaking existing normal practices, though after the patch is made it still wouldn't take care of people using old versions of git without that patch. What do you think? Thanks, Jonathan -- 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
Re: Tight submodule bindings
On Mon, Jan 13, 2014 at 08:37:37PM +0100, Jens Lehmann wrote: Am 12.01.2014 02:08, schrieb W. Trevor King: For folks who treat the submodule as a black box (and do no local development), switchable trees are all they care about. They can easily checkout (or not, with deinit), the submodule tree at a gitlinked hash, and everything is nice and reproducible. The fact that 'submod' is stored as a commit object and not a tree, is just a convenient marker for optional init/deinit/remote-update-integration functionality. But there are users (like me) who do not treat submodules as black boxes and nonetheless do development in them with update set to checkout (after creating a feature branch of course ;-). I'm still not clear on how this works for you ;). Can you sketch out an example shell history showing how you use checkout updates to do this? When you checkout a submodule for the first time, Git should take the default information from .gitmodules and file it away in the submodule's appropriate out-of-tree config locations. I disagree, that only makes sense for the URL setting (and this currently only happens with the update setting, which I intend to change). Everything else should be taken from .gitmodules unless the user wants to override it. The only setting I'm not so sure about is the local branch setting, as that might have to propagate into the submodule. I think copying into the submodule's out-of-tree config is the way to go, because users won't always be driving the submodule from the superproject. If the settings are in the submodule's out-of-tree config, everything will be consistent betwee stuff run from the superproject and stuff run from submodule itself. It also allows us to use familiar configuration commands inside the submodule, and have those automatically mapped back into the .gitmodules file for us. In fact, I think life is easier for everyone if this is the default, and we add a new option (submodule.name.sync = false) that says “don't overwrite optional settings in my submodule's out-of-tree config on checkout” for for folks who want to opt out. Don't worry, this is not going to clobber people, because we'll be syncing the other way too. Yet another flag to make peoples life easier? I don't think so ;-) I'm fine if there is no opt-out, and the syncing is mandatory, but I imagine that folks who want a local (unshared, not in .gitmodules) URL would complain. Purely local metadata - Some metadata does not make sense in the superproject tree. For example, whether a submodule is interesting enough to checkout (init/deinit) or whether you want to auto-sync optional metadata .gitmodules defaults. This metadata should live in the superproject's out-of-tree config, and should not be stored in the in-tree .gitmodules. Not always. It makes a lot of sense to let upstream mark a submodule as too big and you won't need it anyway in the .gitmodules file. Good. Then there's no need for this special class of settings. Since you *will* want to share the upstream URL, I proposed using an explicit submodule.name.active setting to store the “do I care” information [2], instead of overloading submodule.name.url (I'd auto-sync the .gitmodule's submodule.name.url with the subproject's remote.origin.url unless the user opted out of .gitmodules syncing). That is wrong as it would break horribly when you check out an old commit with a now dead submodule URL and that gets automatically synced. If you've already checked out the submodule with a current URL, you should already have the old commit locally, and Git will use it without trying to re-fetch from the broken old URL. Subsequent checkouts Now that we have strict linking between the submodule state (both in-tree and out-of-tree configs) and the superproject tree (gitlink and .gitmodules), changing between superproject branches is really easy: 1. Make sure the working tree is not dirty. If it is, ask the user to either add-and-commit or stash, and then die to let them do so. This condition is too hard, relax that to a trivial merge can switch from current state to target state and make it behave just like branch switching in the superproject. After all submodules should behave as much as possible like content of the superproject. Sounds good to me. Clobber submodule configs and local branches at will (modulo submodule.name.sync), because any submodule configs that the user wanted to keep should have been added to the superproject branch earlier (or stashed). I don't think I like this part, but I admit I do not fully understand what you mean here. Clobbering stuff the user did doesn't sound very nice. It's fine because we forced them to commit or stash any (not trivially mergable) changes before starting the checkout command.
Re: [PATCH 3/3] remote: introduce and fill branch-pushremote
Jeff King p...@peff.net writes:
It does not matter for actually pushing, because to do a non-default
push, you must always specify a remote. But @{publish} will ask the
question even if I am on 'side' now, what would happen if I were to
default-push on 'master'?.
In a similar wording to yours, it can be said that B@{upstream} is
what would happen if I were to default-pull on 'B'?.
A related tangent is what should B@{publish} should yield when there
is no triangular configuration variables like remote.pushdefault,
branch.B.pushremote and a possible future extension branch.B.push
are defined. The definition you gave, i.e. if I were to
default-push, gives a good guideline, I think.
I.e. git push origin master does tell us to push out 'master', but
it does not explicitly say what ref to update. It may be set to
update their remotes/satellite/master when we are emulating a fetch
in reverse by pushing, via e.g.
[remote origin]
push = refs/heads/master:refs/remotes/satellite/master
and it would be intuitive if we make master@{publish} resolve to
refs/remotes/satellite/master in such a case.
One thing that makes things a bit fuzzy is what should happen if
you have more than one push destinations. For example:
[remote home]
pushurl = ...
push = refs/heads/master:refs/remotes/satellite/master
[remote github]
pushurl = ...
mirror
[remote]
pushdefault = ???
git push home updates their 'refs/remotes/satellite/master' with
my 'master' with the above, while git push github will update
their 'refs/heads/master' with 'master'.
We can say master@{publish} is 'remotes/satellite/master' if
remote.pushdefault (or 'branch.master.pushremote) is set to 'home',
it is 'master' if it is 'github', and if git push while sitting on
'master' does not push it anywhere then master@{publish} is an
error. There may be a better definition of what if I were to
default-push really means, but I don't think of any offhand.
--
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
Re: [PATCH 3/3] remote: introduce and fill branch-pushremote
On Mon, Jan 13, 2014 at 12:15:08PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
It does not matter for actually pushing, because to do a non-default
push, you must always specify a remote. But @{publish} will ask the
question even if I am on 'side' now, what would happen if I were to
default-push on 'master'?.
In a similar wording to yours, it can be said that B@{upstream} is
what would happen if I were to default-pull on 'B'?.
Right. I wondered at first if there was a similar bug in @{upstream},
but as I noted earlier, it is not defined if a per-branch remote is not
set. The answer to your question above is nothing, so we do not have
to worry about it. :)
A related tangent is what should B@{publish} should yield when there
is no triangular configuration variables like remote.pushdefault,
branch.B.pushremote and a possible future extension branch.B.push
are defined. The definition you gave, i.e. if I were to
default-push, gives a good guideline, I think.
Yes, that is what I tried for with my original patches. (e.g.,
push.default=upstream should just make @{publish} a synonym for
@{upstream}, which is what my patch did). I punted on simple, but it
would ideally do the same thing as push. Which is why I do not think
my patches are appropriate as-is; they need to somehow share the logic
with git push rather than try to reimplement it.
I.e. git push origin master does tell us to push out 'master', but
it does not explicitly say what ref to update. It may be set to
update their remotes/satellite/master when we are emulating a fetch
in reverse by pushing, via e.g.
[remote origin]
push = refs/heads/master:refs/remotes/satellite/master
and it would be intuitive if we make master@{publish} resolve to
refs/remotes/satellite/master in such a case.
Right. And my patches did that (or at least I intended them to :) ) by
applying the push refspec (if any), and then applying the fetch refspec
on top of that. But again, that seems like policy that should be shared
with git push.
That being said, I do not think your example is the best one for
@{publish}. You have not specified any remote at all. I think the
closest push behavior for @{publish} would be something like:
git checkout master git push
I.e., where would _that_ push go?
One thing that makes things a bit fuzzy is what should happen if
you have more than one push destinations. For example:
[remote home]
pushurl = ...
push = refs/heads/master:refs/remotes/satellite/master
[remote github]
pushurl = ...
mirror
[remote]
pushdefault = ???
git push home updates their 'refs/remotes/satellite/master' with
my 'master' with the above, while git push github will update
their 'refs/heads/master' with 'master'.
We can say master@{publish} is 'remotes/satellite/master' if
remote.pushdefault (or 'branch.master.pushremote) is set to 'home',
it is 'master' if it is 'github', and if git push while sitting on
'master' does not push it anywhere then master@{publish} is an
error. There may be a better definition of what if I were to
default-push really means, but I don't think of any offhand.
Exactly. I do not think the multiple push destinations matter here,
because it is always what would I do if I were on the branch. At most
one of them can be the default in that case (based on the config as you
noted).
-Peff
--
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
Re: Re: Submodule relative URL problems
Hi, On Mon, Jan 13, 2014 at 11:55:18AM -0800, Jonathan Nieder wrote: Lianheng Tong wrote: git clone W1:path to A on W1/.git path to A on W2 Interesting. Thoughts: * More typical usage is to clone from a bare repository (A.git), which wouldn't have this problem. But I think your case is worth supporting, too. * What would you think of putting symlinks in A's .git directory? cd A/.git ln -s ../B ../C ../D . * Perhaps as a special case when the superproject is foo/.git, git should treat relative submodule paths as relative to foo/ instead of relative to foo/.git/. I think that would take care of your case without breaking existing normal practices, though after the patch is made it still wouldn't take care of people using old versions of git without that patch. What do you think? I do not fully get the repository layout, since some commands simply do not work. Nevertheless I think what Lianheng Tong is running into is the following: * If a superproject has *no remote* a relative submodule url is relative to the *superproject itself* * If a superproject has *a remote* a relative submodule url is relative to the *superprojects remote* The simplest solution is: Have central bare repositories for everything so that every workstation has the same remote. The second solution: Make sure both repositories have each other as a remote. But then you run into a chicken/egg problem when setting the two up. The interpretation of relative urls was a design decision back when the relative urls were introduced. I am quite sure it would produce a lot of fallout if we change that. If I get your usecase wrong it would be very helpful if you could provide us with a working script that creates the repository setup your are using. Cheers Heiko -- 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
Re: Submodule relative URL problems
Jonathan Nieder jrnie...@gmail.com writes: * More typical usage is to clone from a bare repository (A.git), which wouldn't have this problem. But I think your case is worth supporting, too. I think the relative URL among nested submodules was specifically designed for hosting environments that have forest of bare repositories to serve as publishing or meeting points. I personally do not know where that worth supporting comes from, but if the change can be done without confusing the codepaths involved, I wouldn't object too much ;-) * Perhaps as a special case when the superproject is foo/.git, git should treat relative submodule paths as relative to foo/ instead of relative to foo/.git/. I think that would take care of your case without breaking existing normal practices, though after the patch is made it still wouldn't take care of people using old versions of git without that patch. What do you think? If we were to start adding special cases, it may also be sensible to clean up the more normal case of using subdirectories of bare repositories to represent nestedness (i.e. you can have a submodule logs.git, but not logs). We could reuse the $GIT_DIR/modules/$sm_name convention somehow perhaps? Any change to implement the special case you suggest likely has to touch the same place as such a change does, as both require some reorganization of the code that traverses the pathnames to find related repositories. -- 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
Re: Tight submodule bindings
W. Trevor King wk...@tremily.us writes: Additional metadata, the initial checkout, and syncing down --- However, folks who do local submodule development will care about which submodule commit is responsible for that tree, because that's going to be the base of their local development. They also care about additional out-of-tree information, including the branch that commit is on. Well, please step back a bit. They do not have to care about what local branch they use to build follow-up work based on that commit. In fact, they would want to be able to develop more than one histories on top, which means more than one branches they can name themselves. The only thing they care about is where the result of their development _goes_, that is the URL and the branch of the remote they are pushing back to. I have a feeling that this is not specific for submodules---if you did this: git init here cd here git fetch $there master git reset --hard FETCH_HEAD and are given the resulting working tree to start hacking on, you would not know where the history came from, or where your result wants to go. So the branch that commit is on is a wrong thing to focus on. The branch the history built on top of the commit wants to go may be closer and these two are different. For already-initialized submodules, there are existing places in the submodule config to store this configuration: 1. HEAD for the checked-out branch, 2. branch.name.remote → remote.name.url for the upstream subproject URL, 4. branch.name.rebase (or pull.rebase) to prefer rebase over merge for integration, 5. … What happened to 3 ;-)? And also branch.name.merge may say on which of _their_ branch the commit you learn in the superproject tree would be found. If you are using centralized workflow, that would be the branch at your central repository to update with your push, too. In any case, local-branch is wrong from two aspects: 1. (obvious) It does not follow our naming convention not to use dashed-names for configuration variables. 2. You do not care about the names you use locally. The only thing you care about is where people meet at the central repository, i.e. where your result is pushed to. Syncing up -- In the previous section I explained how data should flow from .gitmodules into out-of-tree configs. s/should/you think should/, I think, but another way may be not to copy and read from there, which may be a lot simpler. Then upon switching branches of top-level superproject (which would update .gitmodules to the version on the new branch), you may get different settings automatically. But see below. ... Since you *will* want to share the upstream URL, I proposed using an explicit submodule.name.active setting to store the “do I care” information [2], instead of overloading submodule.name.url (I'd auto-sync the .gitmodule's submodule.name.url with the subproject's remote.origin.url unless the user opted out of .gitmodules syncing). It may not be a good idea to blindly update to whatever happens to be in .gitmodules, especially once submodule.*.url is initialized. I think we would need a bit more sophisticated mechanism than use from .git/config if set, otherwise use from .gitmodules, at least for the URL. It may not be limited to the URL, and other pieces of metainformation about submodules may need similar handling, but I'd refrain from extending the scope of discussion needlessly at this point. Imagine that your embedded appliance project used to use a submodule from git://k.org/linux-2.6 as its kernel component and now the upstream of it is instead called just git://k.org/linux; the URL specified by submodule.kernel.url in .gitmodules for the entry submodule.kernel.path=kernel would have changed from the former to the latter sometime in the superproject's history. Switching back to an old version in the superproject to fix an old bug in the maintenance track of the superproject would still want to push associated fixes to the kernel to k.org/linux, not linux-2.6, the latter of which may now be defunct [*1*]. One way to make it work semi-automatically is to keep track of what the user has seen in .gitmodules and offer chances to update entries in .git/config. If you cloned the superproject recently, you would only know about the new git://k.org/linux URL and that would be copied to .git/config (which the current code does). In addition, you would remember that we saw git://k.org/linux URL (which the current code does not). Upon switching back to an old version, we could notice that the URL in .gitmodules, which is git://k.org/linux-2.6, is not something the user has seen, and at that point we could ask the user to tell us what URL should be used, record the answer _and_ the fact that we saw that old URL as well. Then until the superproject updates the URL the next time to a
Re: [RFC v2] blame: new option --prefer-first to better handle merged cherry-picks
Bernhard R. Link brl...@debian.org writes: Allows to disable the git blame optimization of assuming that if there is a parent of a merge commit that has the exactly same file content, then only this parent is to be looked at. This optimization, while being faster in the usual case, means that in the case of cherry-picks the blamed commit depends on which other commits touched a file. If for example one commit A modified both files b and c. And there are commits B and C, B only modifies file b and C only modifies file c (so that no conflicts happen), and assume A is cherry-picked as A' and the two branches then merged: --o-B---A \ \ ---C---A'--M--- Then without this new option git blame blames the A|A' changes of file b to A while blaming the changes of c to A'. With the new option --prefer-first it blames both changes to the same commit and to the one more on the left side of the graph. Signed-off-by: Bernhard R. Link brl...@debian.org --- Documentation/blame-options.txt | 6 ++ builtin/blame.c | 7 +-- 2 files changed, 11 insertions(+), 2 deletions(-) Differences to first round: rename option and describe the effect instead of the implementation in documentation. I read the updated documentation three times but it still does not answer any of my questions I had in $gmane/239888, the most important part of which was: Yeah, the cherry-picked one will introduce the same change as the one that was cherry-picked, so if you look at the end result and ask where did _this_ line come from?, there are two equally plausible candidates, as blame output can give only one answer to each line. I still do not see why the one that is picked with the new option is better. At best, it looks to me that it is saying running with this option may (or may not) give a different answer, so run the command with and without it and see which one you like, which does not sound too useful to the end users. To put it another way, why/when would an end user choose to use this option? If the result of using this option is always better than without, why/when would an end user choose not to use this option? diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt index 0cebc4f..b2e7fb8 100644 --- a/Documentation/blame-options.txt +++ b/Documentation/blame-options.txt @@ -48,6 +48,12 @@ include::line-range-format.txt[] Show the result incrementally in a format designed for machine consumption. +--prefer-first:: + If a line was introduced by two commits (for example via + a merged cherry-pick), prefer the commit that was + first merged in the history of always following the + first parent. + --encoding=encoding:: Specifies the encoding used to output author names and commit summaries. Setting it to `none` makes blame -- 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
Re: [RFC v2] blame: new option --prefer-first to better handle merged cherry-picks
* Junio C Hamano gits...@pobox.com [140113 23:31]: I read the updated documentation three times but it still does not answer any of my questions I had in $gmane/239888, the most important part of which was: Yeah, the cherry-picked one will introduce the same change as the one that was cherry-picked, so if you look at the end result and ask where did _this_ line come from?, there are two equally plausible candidates, as blame output can give only one answer to each line. I still do not see why the one that is picked with the new option is better. Because: - it will blame the modifications of merged cherry-picked commit to only one commit. Without the option parts of the modification will be reported as coming from the one, parts will be reported to be from the other. With the option only one of those two commits is reported as the origin at the same time and not both. - it is more predictable which commit is blamed, so if one is interested in where some commit was introduced first into a mainline, one gets this information, and not somtimes a different one due to unrelated reasons. To put it another way, why/when would an end user choose to use this option? If the result of using this option is always better than without, why/when would an end user choose not to use this option? While the result is more consistent and more predictable in the case of merged cherry picks, it is also slower in every case. Usually speed will be more important than this exactness, especially as the result will not differ for the common case (if there are no cherry-picked commits merged or when those commits do not touch any files that are otherwise only modified in the merged branch). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- 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
Re: [RFC v2] blame: new option --prefer-first to better handle merged cherry-picks
Bernhard R. Link brl+...@mail.brlink.eu writes: * Junio C Hamano gits...@pobox.com [140113 23:31]: I read the updated documentation three times but it still does not answer any of my questions I had in $gmane/239888, the most important part of which was: Yeah, the cherry-picked one will introduce the same change as the one that was cherry-picked, so if you look at the end result and ask where did _this_ line come from?, there are two equally plausible candidates, as blame output can give only one answer to each line. I still do not see why the one that is picked with the new option is better. Because: - it will blame the modifications of merged cherry-picked commit to only one commit. Without the option parts of the modification will be reported as coming from the one, parts will be reported to be from the other. With the option only one of those two commits is reported as the origin at the same time and not both. - it is more predictable which commit is blamed, so if one is interested in where some commit was introduced first into a mainline, one gets this information, and not somtimes a different one due to unrelated reasons. To put it another way, why/when would an end user choose to use this option? If the result of using this option is always better than without, why/when would an end user choose not to use this option? While the result is more consistent and more predictable in the case of merged cherry picks, it is also slower in every case. Consistent and predictable, perhaps, but I am not sure exact would be a good word. Wouldn't the result depend on which way the cherry pick went, and then the later merge went? In the particular topology you depicted in the log message, the end result may happen to point at the same commit for these two paths, but I am not sure how the change guarantees that we always point at the same original commit not the cherry-picked one, which was implied by the log message, if your cherry-pick and merge went in different direction in similar topologies. And that is why I said: At best, it looks to me that it is saying running with this option may (or may not) give a different answer, so run the command with and without it and see which one you like With the stress on different answer; it the change were with the option the result is always better, albeit you will have to wait longer, I would not have this much trouble accepting the change, though. -- 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
Re: [PATCH] git-p4: Do not include diff in spec file when just preparing p4
frrr...@gmail.com wrote on Mon, 13 Jan 2014 12:10 +: Hello, On Sun, Jan 12, 2014 at 05:29:46PM -0500, Pete Wyckoff wrote: Thanks for the patch, but I'm curious how you'd like this to work. I never use the option myself. As it is, --prepare-p4-only generates a file in /tmp/ that has exactly the contents you'd see in the editor during git p4 submit. It includes the diff of the change, presumably to help with writing the description. Yes, I believe it makes sense to display the diff in this case, as we can remove it later programmatically. Now you can't actually feed this file directly to p4 submit without deleting the diff. That's the part you don't like? Yes, I do not use that for submitting, but for shelving. I can run git p4 submit --prepare-p4-only followed by p4 shelve -i /tmp/... and perforce will shelve the corresponding change. Removing the diff could be done externally, however git-p4 itself tells the user it can submit using the generated file, which is not the case if we keep the diff in it. I'm convinced. That explanation makes sense, thanks. It would be nice to do a few more things with this patch. Here's some ideas, sorted in priority order. 1. Put slightly more text into the commit message, possibly from your email above. 2. Refactor out that big chunk of code instead of just moving it. Selectively call it only if not prepare_p4_only. 3. Modify the t9807 test 'submit --prepare-p4-only' to make sure the diff isn't there. 4. Documentation update? Probably not necessary. Let me know if you're interested in doing any of this. -- Pete -- 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
git gui crashes ( v 1.8.5.2)
Hello,
git gui crashes on my Linux machin since I updated it to 1.8.5.2.
I had the message
Error in startup script: unknown option -stretch
while executing
.vpane.lower paneconfigure .vpane.lower.diff -stretch always
invoked from within
if {$use_ttk} {
.vpane.lower pane .vpane.lower.diff -weight 1
.vpane.lower pane .vpane.lower.commarea -weight 0
} else {
.vpane.lower paneconfigure...
(file git/libexec/git-core/git-gui line 3233)
So, I reverted the change that has been made in git-gui/git-gui.sh
(Diff and Commit Area)
I replaced
${NS}::panedwindow .vpane.lower -orient vertical
${NS}::frame .vpane.lower.commarea
${NS}::frame .vpane.lower.diff -relief sunken -borderwidth 1 -height 500
.vpane.lower add .vpane.lower.diff
.vpane.lower add .vpane.lower.commarea
.vpane add .vpane.lower
by
${NS}::frame .vpane.lower -height 300 -width 400
${NS}::frame .vpane.lower.commarea
${NS}::frame .vpane.lower.diff -relief sunken -borderwidth 1
pack .vpane.lower.diff -fill both -expand 1
pack .vpane.lower.commarea -side bottom -fill x
.vpane add .vpane.lower
if {!$use_ttk} {.vpane paneconfigure .vpane.lower -sticky nsew}
and now, git gui works as expected.
Regards,
Benoit
--
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
Re: git-p4: exception when cloning a perforce repository
dam...@iwi.me wrote on Mon, 13 Jan 2014 14:37 +0100:
I am trying to clone a perforce repository via git and I am having the
following backtrace :
{14:20}~/projects/:master ✗ ➭ git p4 clone //depot/@all .
Importing revision …
[...]
Importing revision 59702 (45%)Traceback (most recent call last):
[..]
File /opt/git/libexec/git-core/git-p4, line 2078, in streamOneP4File
if data[-1] == '\n':
IndexError: string index out of range
git —version: git version 1.8.5.2.309.ga25014b [last commit from master from
github.com/git/git]
os : ubuntu 13.10
This code:
if type_base == symlink:
git_mode = 12
# p4 print on a symlink sometimes contains target\n;
# if it does, remove the newline
data = ''.join(contents)
== if data[-1] == '\n':
contents = [data[:-1]]
else:
contents = [data]
means that data is an empty string. Implies you've got a
symlink pointing to nothing. Is that even possible?
It could be this is a regression introduced at 1292df1 (git-p4:
Fix occasional truncation of symlink contents., 2013-08-08). The
old way of doing data[:-1] unconditionally would have worked but
was broken for other reasons.
Could you investigate the symlink a bit? We're looking for
one in change 59702 that points to nowhere. Maybe do:
$ p4 describe -s 59702
and see if you can figure out which of those could be a symlink, then
inspect it:
$ p4 fstat //depot/symlink@59702
(probably shows it is headRev 1)
$ p4 print -q //depot/symlink#1
$ p4 print -q //depot/symlink#1 | od -c
Thanks for checking this depot info first.
-- Pete
--
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
Re: git gui crashes ( v 1.8.5.2)
(just cc-ing some area experts)
Hi Benoît,
Benoît Bourbié wrote:
git gui crashes on my Linux machin since I updated it to 1.8.5.2.
I assume you mean master and not 1.8.5.2, since v1.8.5.2 doesn't
include the change 918dbf58 (git-gui: right half window is paned,
2013-08-21).
I had the message
Error in startup script: unknown option -stretch
while executing
.vpane.lower paneconfigure .vpane.lower.diff -stretch always
invoked from within
if {$use_ttk} {
.vpane.lower pane .vpane.lower.diff -weight 1
.vpane.lower pane .vpane.lower.commarea -weight 0
} else {
.vpane.lower paneconfigure...
(file git/libexec/git-core/git-gui line 3233)
So, I reverted the change that has been made in git-gui/git-gui.sh
(Diff and Commit Area)
I replaced
${NS}::panedwindow .vpane.lower -orient vertical
${NS}::frame .vpane.lower.commarea
${NS}::frame .vpane.lower.diff -relief sunken -borderwidth 1 -height 500
.vpane.lower add .vpane.lower.diff
.vpane.lower add .vpane.lower.commarea
.vpane add .vpane.lower
by
${NS}::frame .vpane.lower -height 300 -width 400
${NS}::frame .vpane.lower.commarea
${NS}::frame .vpane.lower.diff -relief sunken -borderwidth 1
pack .vpane.lower.diff -fill both -expand 1
pack .vpane.lower.commarea -side bottom -fill x
.vpane add .vpane.lower
if {!$use_ttk} {.vpane paneconfigure .vpane.lower -sticky nsew}
and now, git gui works as expected.
Thanks,
Jonathan
--
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
Re: [PATCH 2/6] read-cache: new extension to mark what file is watched
On Tue, Jan 14, 2014 at 12:02 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Nguyễn Thái Ngọc Duy wrote:
If an entry is watched, git lets an external program decide if the
entry is modified or not. It's more like --assume-unchanged, but
designed to be controlled by machine.
We are running out of on-disk ce_flags, so instead of extending
on-disk entry format again, watched flags are in-core only and
stored as extension instead.
Makes sense.
Care to add a brief description of the on-disk format for
Documetnation/technical/index-format.txt as well?
Sure, in the reroll after I fix inotify bugs that make the test suite fail.
+static void read_watch_extension(struct index_state *istate, uint8_t *data,
+ unsigned long sz)
+{
+ int i;
+ if ((istate-cache_nr + 7) / 8 != sz) {
+ error(invalid 'WATC' extension);
+ return;
+ }
+ for (i = 0; i istate-cache_nr; i++)
+ if (data[i / 8] (1 (i % 8)))
+ istate-cache[i]-ce_flags |= CE_WATCHED;
+}
So the WATC section has one bit per index entry, encoding whether that
entry is WATCHED. Makes sense.
Do I understand correctly that this patch just takes care of the
bookkeeping for the CE_WATCHED bit and the actual semantics will
come in a later patch?
Correct.
--
Duy
--
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
Re: [PATCH 2/6] read-cache: new extension to mark what file is watched
On Sun, Jan 12, 2014 at 6:03 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: We are running out of on-disk ce_flags, Correction, we're not. I saw /* * Extended on-disk flags */ #define CE_INTENT_TO_ADD (1 29) #define CE_SKIP_WORKTREE (1 30) followed by /* CE_EXTENDED2 is for future extension */ #define CE_EXTENDED2 (1 31) and panicked, but on-disk flags could be added backward (e.g. bit 28, 27...). Anyway using extended flags means 2 extra bytes per entry for almost every entry in this case (and for index v5 it means redoing crc32 for almost every entry too when the bit is updated) so it may still be a good idea to keep the new flag separate. so instead of extending on-disk entry format again, watched flags are in-core only and stored as extension instead. -- Duy -- 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
BUG: manpage for git-pull mentions a non-valid option -m in a comment
Hello! git-1.8.4.4 The manpage for git-pull mentions -m in a comment: --edit, -e, --no-edit Invoke an editor before committing successful mechanical merge to further edit the auto-generated merge message, so that the user can explain and justify the merge. The --no-edit option can be used to accept the auto-generated message (this is generally discouraged). The --edit (or -e) option is still useful if you are giving a draft message with the -m option from the command line and want to edit it in the editor. but it is not accepted actually: git pull --no-edit -m 'Restoring config etc from server' \ origin server/GITCONFIG/master fatal: No such remote or remote group: Restoring config etc from server I'm not sure whether it is a bug of the implementation or of the documentation. (I've also written down this issue at https://bugzilla.altlinux.org/show_bug.cgi?id=29718 .) Best regards, Ivan -- 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
Re: Tight submodule bindings
On Mon, Jan 13, 2014 at 02:13:46PM -0800, Junio C Hamano wrote: W. Trevor King wk...@tremily.us writes: Additional metadata, the initial checkout, and syncing down --- However, folks who do local submodule development will care about which submodule commit is responsible for that tree, because that's going to be the base of their local development. They also care about additional out-of-tree information, including the branch that commit is on. Well, please step back a bit. They do not have to care about what local branch they use to build follow-up work based on that commit. They do if they want to checkout the banch out again later, before pushing it somewhere public. In fact, they would want to be able to develop more than one histories on top, which means more than one branches they can name themselves. Agreed, bug for each superproject branch they will still have a single submodule branch that should be checked out by default when they checkout that superproject branch. The only thing they care about is where the result of their development _goes_, that is the URL and the branch of the remote they are pushing back to. Maybe they're just doing local development? I think the remote branch(es) you pull from and push to are important, but not the only thing you might care about. I have a feeling that this is not specific for submodules---if you did this: git init here cd here git fetch $there master git reset --hard FETCH_HEAD and are given the resulting working tree to start hacking on, you would not know where the history came from, or where your result wants to go. So the branch that commit is on is a wrong thing to focus on. The branch the history built on top of the commit wants to go may be closer and these two are different. That makes sense. I don't think the former (as distinct from the latter) is of any interest to anybody. I don't care what the branch name was when the past history was developed. I don't even really care about the new branch name. I do care that checking out a superproject branch gives me the same branch (with pull/push configs, etc.) that I had the last time I was on that superproject branch. For already-initialized submodules, there are existing places in the submodule config to store this configuration: 1. HEAD for the checked-out branch, 2. branch.name.remote → remote.name.url for the upstream subproject URL, 4. branch.name.rebase (or pull.rebase) to prefer rebase over merge for integration, 5. … What happened to 3 ;-)? I can't count? :p In any case, local-branch is wrong from two aspects: 1. (obvious) It does not follow our naming convention not to use dashed-names for configuration variables. I'll use localBranch in my mockup ;). Although skimming through config.txt shows a number of alllowercase settings as well as camelCase. 2. You do not care about the names you use locally. The only thing you care about is where people meet at the central repository, i.e. where your result is pushed to. I also care about local-checkout consistency, as described above. Syncing up -- In the previous section I explained how data should flow from .gitmodules into out-of-tree configs. s/should/you think should/, I think, but another way may be not to copy and read from there, which may be a lot simpler. Then upon switching branches of top-level superproject (which would update .gitmodules to the version on the new branch), you may get different settings automatically. That only works for superproject-level commands that know about the .gitmodules file. If you cd into the submodule and work there directly, your actions will be using the submodule's out-of-tree config. I think most of the time folks will want those out-of-tree configs to match the settings in the superproject's .gitmodules, hence the submodule.name.sync defaulting to true. ... Since you *will* want to share the upstream URL, I proposed using an explicit submodule.name.active setting to store the “do I care” information [2], instead of overloading submodule.name.url (I'd auto-sync the .gitmodule's submodule.name.url with the subproject's remote.origin.url unless the user opted out of .gitmodules syncing). It may not be a good idea to blindly update to whatever happens to be in .gitmodules, especially once submodule.*.url is initialized. Why not? We're blindly updating it to the value that was previously pulled out of the submodule's out-of-tree config. If the user doesn't like what's happening to .gitmodules upstream and doesn't want to keep a patched version locally, they can always turn off submodule.name.sync. Imagine that your embedded appliance project used to use a submodule from git://k.org/linux-2.6 as its kernel component and now the upstream of it is
[PATCH] gitattributes: document more clearly where macros are allowed
The old text made it sound like macros are only allowed in the .gitattributes file at the top-level of the working tree. Make it clear that they are also allowed in $GIT_DIR/info/attributes and in the global and system-wide gitattributes files. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/gitattributes.txt | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index b322a26..643c1ba 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -930,9 +930,12 @@ state. DEFINING MACRO ATTRIBUTES - -Custom macro attributes can be defined only in the `.gitattributes` -file at the toplevel (i.e. not in any subdirectory). The built-in -macro attribute binary is equivalent to: +Custom macro attributes can be defined only in top-level gitattributes +files (`$GIT_DIR/info/attributes`, the `.gitattributes` file at the +top level of the working tree, or the global or system-wide +gitattributes files), not in `.gitattributes` files in working tree +subdirectories. The built-in macro attribute binary is equivalent +to: [attr]binary -diff -merge -text -- 1.8.5.2 -- 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
[PATCH] refname_match(): always use the rules in ref_rev_parse_rules
We used to use two separate rules for the normal ref resolution
dwimming and dwimming done to decide which remote ref to grab. The
third parameter to refname_match() selected which rules to use.
When these two rules were harmonized in
2011-11-04 dd621df9cd refs DWIMmery: use the same rule for both git fetch
and others
, ref_fetch_rules was #defined to avoid potential breakages for
in-flight topics.
It is now safe to remove the backwards-compatibility code, so remove
refname_match()'s third parameter, make ref_rev_parse_rules private to
refs.c, and remove ref_fetch_rules entirely.
Suggested-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
See
http://article.gmane.org/gmane.comp.version-control.git/240305
in which Junio made the suggestion and wrote most of the commit
message :-)
cache.h | 9 ++---
refs.c | 6 +++---
remote.c | 8
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/cache.h b/cache.h
index 83a2726..508c49a 100644
--- a/cache.h
+++ b/cache.h
@@ -893,9 +893,12 @@ extern int dwim_log(const char *str, int len, unsigned
char *sha1, char **ref);
extern int interpret_branch_name(const char *str, int len, struct strbuf *);
extern int get_sha1_mb(const char *str, unsigned char *sha1);
-extern int refname_match(const char *abbrev_name, const char *full_name, const
char **rules);
-extern const char *ref_rev_parse_rules[];
-#define ref_fetch_rules ref_rev_parse_rules
+/*
+ * Return true iff abbrev_name is a possible abbreviation for
+ * full_name according to the rules defined by ref_rev_parse_rules in
+ * refs.c.
+ */
+extern int refname_match(const char *abbrev_name, const char *full_name);
extern int create_symref(const char *ref, const char *refs_heads_master, const
char *logmsg);
extern int validate_headref(const char *ref);
diff --git a/refs.c b/refs.c
index 490b57b..fc33ee8 100644
--- a/refs.c
+++ b/refs.c
@@ -1880,7 +1880,7 @@ const char *prettify_refname(const char *name)
0);
}
-const char *ref_rev_parse_rules[] = {
+static const char *ref_rev_parse_rules[] = {
%.*s,
refs/%.*s,
refs/tags/%.*s,
@@ -1890,12 +1890,12 @@ const char *ref_rev_parse_rules[] = {
NULL
};
-int refname_match(const char *abbrev_name, const char *full_name, const char
**rules)
+int refname_match(const char *abbrev_name, const char *full_name)
{
const char **p;
const int abbrev_name_len = strlen(abbrev_name);
- for (p = rules; *p; p++) {
+ for (p = ref_rev_parse_rules; *p; p++) {
if (!strcmp(full_name, mkpath(*p, abbrev_name_len,
abbrev_name))) {
return 1;
}
diff --git a/remote.c b/remote.c
index a89efab..e41251e 100644
--- a/remote.c
+++ b/remote.c
@@ -1000,7 +1000,7 @@ int count_refspec_match(const char *pattern,
char *name = refs-name;
int namelen = strlen(name);
- if (!refname_match(pattern, name, ref_rev_parse_rules))
+ if (!refname_match(pattern, name))
continue;
/* A match is weak if it is with refs outside
@@ -1571,7 +1571,7 @@ int branch_merge_matches(struct branch *branch,
{
if (!branch || i 0 || i = branch-merge_nr)
return 0;
- return refname_match(branch-merge[i]-src, refname, ref_fetch_rules);
+ return refname_match(branch-merge[i]-src, refname);
}
static int ignore_symref_update(const char *refname)
@@ -1624,7 +1624,7 @@ static const struct ref *find_ref_by_name_abbrev(const
struct ref *refs, const c
{
const struct ref *ref;
for (ref = refs; ref; ref = ref-next) {
- if (refname_match(name, ref-name, ref_fetch_rules))
+ if (refname_match(name, ref-name))
return ref;
}
return NULL;
@@ -2121,7 +2121,7 @@ static void apply_cas(struct push_cas_option *cas,
/* Find an explicit --option=name[:value] entry */
for (i = 0; i cas-nr; i++) {
struct push_cas *entry = cas-entry[i];
- if (!refname_match(entry-refname, ref-name,
ref_rev_parse_rules))
+ if (!refname_match(entry-refname, ref-name))
continue;
ref-expect_old_sha1 = 1;
if (!entry-use_tracking)
--
1.8.5.2
--
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
Re: git gui crashes ( v 1.8.5.2)
Hello Jonathan,
Yes, after checking, you are absolutely right, I was on master.
:)
On Mon, Jan 13, 2014 at 7:11 PM, Jonathan Nieder jrnie...@gmail.com wrote:
(just cc-ing some area experts)
Hi Benoît,
Benoît Bourbié wrote:
git gui crashes on my Linux machin since I updated it to 1.8.5.2.
I assume you mean master and not 1.8.5.2, since v1.8.5.2 doesn't
include the change 918dbf58 (git-gui: right half window is paned,
2013-08-21).
I had the message
Error in startup script: unknown option -stretch
while executing
.vpane.lower paneconfigure .vpane.lower.diff -stretch always
invoked from within
if {$use_ttk} {
.vpane.lower pane .vpane.lower.diff -weight 1
.vpane.lower pane .vpane.lower.commarea -weight 0
} else {
.vpane.lower paneconfigure...
(file git/libexec/git-core/git-gui line 3233)
So, I reverted the change that has been made in git-gui/git-gui.sh
(Diff and Commit Area)
I replaced
${NS}::panedwindow .vpane.lower -orient vertical
${NS}::frame .vpane.lower.commarea
${NS}::frame .vpane.lower.diff -relief sunken -borderwidth 1 -height 500
.vpane.lower add .vpane.lower.diff
.vpane.lower add .vpane.lower.commarea
.vpane add .vpane.lower
by
${NS}::frame .vpane.lower -height 300 -width 400
${NS}::frame .vpane.lower.commarea
${NS}::frame .vpane.lower.diff -relief sunken -borderwidth 1
pack .vpane.lower.diff -fill both -expand 1
pack .vpane.lower.commarea -side bottom -fill x
.vpane add .vpane.lower
if {!$use_ttk} {.vpane paneconfigure .vpane.lower -sticky nsew}
and now, git gui works as expected.
Thanks,
Jonathan
--
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
Re: git gui crashes ( v 1.8.5.2)
Hi. On Mon, Jan 13, 2014 at 05:11:41PM -0800, Jonathan Nieder wrote: (just cc-ing some area experts) Benoît Bourbié wrote: git gui crashes on my Linux machin since I updated it to 1.8.5.2. I believe this happens at tk8.4 or earlier. I have not tested it there, and according to the manpages in Internet the older versions do not have the -stretch option. Before I can find a system to test it, I think the panned right half should really be reverted for the older versions of tk. I remember it did not behave correctly without the stretch option. Maybe, to avoid cluttering the code, panedwindow should nit be used at all without the ttk. I'll try to submit a fix today. -- Max -- 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
