* [RFC/PATCH] fail pull/merge early in the middle of conflicted merge
From: Junio C Hamano @ 2007-01-01 7:21 UTC (permalink / raw)
To: git
After a pull that results in a conflicted merge, a new user
often tries another "git pull" in desperation. When the index
is unmerged, merge backends correctly bail out without touching
either index nor the working tree, so this does not make the
wound any worse.
The user will however see several lines of messsages during this
process, such as "filename: needs merge", "you need to resolve
your current index first", "Merging...", and "Entry ... would be
overwritten by merge. Cannot merge.". They are unnecessarily
alarming, and makes useful conflict messages from the first pull
scroll off the top of the terminal.
This changes pull and merge to run "git-ls-files -u" upfront and
stop them much earlier than we currently do.
Old timers may know better and would not to try pulling again
before cleaning things up; this change adds extra overhead that
is unnecessary for them. But this would be worth paying for to
save new people from needless confusion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I've seen some people on #git channel got totally confused
after a conflicted merge at least three times, and they paste
the diagnostics from the second and subsequent pull, assuming
that the messages would help diagnosing the situation in any
way (unfortunately they typically don't). But it is not the
user's fault not to know it. With this what they can give us
when asking for help will only be from the first pull. In a
sense, the real motivation of this patch is to make life
easier for people who want to help these new people.
git-merge.sh | 3 +++
git-pull.sh | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index ba42260..f43fa69 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -8,6 +8,9 @@ USAGE='[-n] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commi
. git-sh-setup
set_reflog_action "merge $*"
+test -z "$(git ls-files -u)" ||
+ die "You are in a middle of conflicted merge."
+
LF='
'
diff --git a/git-pull.sh b/git-pull.sh
index 28d0819..49130d5 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -9,6 +9,9 @@ LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEA
. git-sh-setup
set_reflog_action "pull $*"
+test -z "$(git ls-files -u)" ||
+ die "You are in a middle of conflicted merge."
+
strategy_args= no_summary= no_commit= squash=
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
do
^ permalink raw reply related
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-01 7:38 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git, Shawn Pearce, Johannes Schindelin, J. Bruce Fields
In-Reply-To: <951491.40207.qm@web31807.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> ...
>> Could you explain a situation where this would be useful?
>
> I don't know how to respond to this question.
>
>> A
>> "parent<-->child" relationship, where there's one upstream branch that
>> is always merged in, is easily handled;
>
> e is the base of natural logarithms.
You lost me here; I am guessing this is some sarcasm not worth
paying attention to, so I'd ignore this part for now.
>> just replace your "git pull parent" by a "git pull", right?
>
> Yes, but I don't want to just type "git-pull", I want to explicitly
> type "git-pull parent" and depending in which branch I'm at, "parent"
> would have identical meaning but would merge a different branch... because
> I'm in a different branch...
>
>> Am I misunderstanding the proposal?
>
> I did give an example of usage in my email to which you replied.
But what confuses me (and I think JBF shares the same confusion
with me) is that you had only one example "parent".
While I understand that it would make sense to define "parent"
for each branch in a downstream developer's workflow, (1) I do
not see the difference between your wording, "parent", and what
we traditionally have called "origin", and (2) I do not think of
relationship other than "parent" ("origin") that is applicable
commonly (in other words, "worth having your 'symbolic'
mechanism for, because it is so commonly applicable") to
branches offhand. Hence, JBF's suggestion to use "git pull"
without using noiseword "parent" or "origin" feels very natural
to me --- if there can be only one valid thing to say, why do
you even have to say it?
Because I do not understand what you would want "parent" for and
why "git pull" is not sufficient, I cannot tell if this would
help solving what you are trying to solve in a different way,
but I suspect a useful thing to have might be a per-branch
alias. For example, we could allow "git merge" without
parameters to alias to "git merge origin/next" when you are on
your 'next' and the same "git merge" could be aliased to "git
merge origin/master" when you are on your 'master'.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-01 7:53 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin
In-Reply-To: <20070101054536.GG15537@fieldses.org>
--- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Sun, Dec 31, 2006 at 09:13:49PM -0800, Luben Tuikov wrote:
> > Yes, but I don't want to just type "git-pull", I want to explicitly
> > type "git-pull parent" and depending in which branch I'm at, "parent"
> > would have identical meaning but would merge a different branch... because
> > I'm in a different branch...
>
> Wouldn't it do what you want if by default "git branch new" and "git
> checkout -b new" set branch.* options that pointed at the "parent"
> branch?
Technically yes. Presentationally no.
> The only reason I can see to require the extra bit of syntax ("git-pull
> parent" instead of "git-pull") is if for the same branch you expect to
> sometimes pull from one source and sometimes from another, and the pulls
> from those various sources are common enough that it's worth defining
> some shortcuts for more than one of them.
Exactly.
> I can imagine sometimes doing that. (E.g. if you pull into your master
> branch from upstream and from local topic branches.) But in that case
> having to give the remote and branch name explicitly doesn't seem so
> bad.
Basically I want to _name_ the dependency, instead of having it be
implicit. One can extend that dependency, in more complicated
topic branch relationship, where for example, C extends B, B extends
A, A extends master, but B' also extends A, consider B' a "version"
of the extension which B implements. This is of course a trivial
example and more complicated ones exist.
Naming the dependency would give git greater coverage when it needs
to implement complicated source development environments and code
relationship. IOW, it is the way to go. Having a single implicit
dependency is just a crutch, half-way there.
Or, one can look at it in a different way, extending the
remote/ functionality as is, but instead of being remote-pulls-
into-local, extending for local pulls into local.
I.e. the remote relationship is named, I'd like to extend
this locally as well.
Consider the examples of "branch.<name>.<symbolic_ref>.{fetch, merge}"
I gave in a previous email in this thread.
Luben
^ permalink raw reply
* [RFC/PATCH] Add builtin git-last-modified.
From: Robert Fitzsimons @ 2007-01-01 7:55 UTC (permalink / raw)
To: git
This is a plumbing command which can be used by gitweb. It will scan
a list of commits and/or refs and return the time in seconds for the
youngest commit. This value can then be used to generate and check
the Last-Modified and Is-Modified-Since HTTP headers.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
The following two commands lines are similar:
$ git for-each-ref --count=1 --sort=-committerdate '--format=%(committerdate)' refs/heads
$ git last-modified --branches
The last-modified version is a bit faster (5-10%).
I'm not 100% sure how this command and if this command should be used
by gitweb. But I'll post the patch anyway for comments.
Robert
.gitignore | 1 +
Documentation/git-last-modified.txt | 49 ++++++++++++++++++++++++++++
Makefile | 3 +-
builtin-last-modified.c | 61 +++++++++++++++++++++++++++++++++++
builtin.h | 1 +
git.c | 1 +
t/t3810-last-modified.sh | 57 ++++++++++++++++++++++++++++++++
7 files changed, 172 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 2904f12..ffca6c5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -58,6 +58,7 @@ git-lost-found
git-ls-files
git-ls-remote
git-ls-tree
+git-last-modified
git-mailinfo
git-mailsplit
git-merge
diff --git a/Documentation/git-last-modified.txt b/Documentation/git-last-modified.txt
new file mode 100644
index 0000000..4584b5d
--- /dev/null
+++ b/Documentation/git-last-modified.txt
@@ -0,0 +1,49 @@
+git-last-modified(1)
+================
+
+NAME
+----
+git-last-modified - Get the last modified time in seconds
+
+
+SYNOPSIS
+--------
+'git-last-modified' [ \--all ]
+ [ \--branches ]
+ [ \--tags ]
+ [ \--remotes ]
+ <commmit>...
+
+DESCRIPTION
+-----------
+
+Get the last modified time in seconds for the youngest commit object
+based on the search criteria. The time value is from the 'commit'
+header of the commit object, ignoring the timezone. The time is
+formatted as an ASCII decimal number and is the number of seconds
+since epoch.
+
+This is a plumbing command used by gitweb to generate and check the
+Last-Modified and Is-Modified-Since HTTP headers.
+
+OPTIONS
+-------
+--all::
+ Search all refs found in `$GIT_DIR/refs`.
+
+--branches::
+ Search branch refs found in `$GIT_DIR/refs/heads`.
+
+--tags::
+ Search tag refs found in `$GIT_DIR/refs/tags`.
+
+--remotes::
+ Search remote refs found in `$GIT_DIR/refs/remotes`.
+
+<commit>...::
+ Search list of commits and refs.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index fa1a022..1f169ac 100644
--- a/Makefile
+++ b/Makefile
@@ -312,7 +312,8 @@ BUILTIN_OBJS = \
builtin-verify-pack.o \
builtin-write-tree.o \
builtin-show-ref.o \
- builtin-pack-refs.o
+ builtin-pack-refs.o \
+ builtin-last-modified.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
EXTLIBS = -lz
diff --git a/builtin-last-modified.c b/builtin-last-modified.c
new file mode 100644
index 0000000..38cfb80
--- /dev/null
+++ b/builtin-last-modified.c
@@ -0,0 +1,61 @@
+#include "cache.h"
+#include "commit.h"
+#include "refs.h"
+#include "builtin.h"
+
+static int lastmod_date(const unsigned char *sha1, unsigned long *date)
+{
+ struct commit *commit = lookup_commit_reference_gently(sha1, 1);
+
+ if (!commit)
+ return 1;
+
+ if (commit->date > *date)
+ *date = commit->date;
+
+ return 0;
+}
+
+static int process_ref(const char *refname, const unsigned char *sha1, int flags, void *cb_data)
+{
+ return lastmod_date(sha1, (unsigned long *)cb_data);
+}
+
+int cmd_last_modified(int argc, const char **argv, const char *prefix)
+{
+ int i;
+ unsigned char sha1[20];
+ unsigned long date = 0;
+
+ git_config(git_default_config);
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+
+ if (!strcmp(arg, "--all")) {
+ for_each_ref(process_ref, &date);
+ continue;
+ }
+ if (!strcmp(arg, "--branches")) {
+ for_each_branch_ref(process_ref, &date);
+ continue;
+ }
+ if (!strcmp(arg, "--tags")) {
+ for_each_tag_ref(process_ref, &date);
+ continue;
+ }
+ if (!strcmp(arg, "--remotes")) {
+ for_each_remote_ref(process_ref, &date);
+ continue;
+ }
+
+ if (get_sha1(arg, sha1))
+ die("last-modified: could not get sha1 for '%s'", arg);
+ if (lastmod_date(sha1, &date))
+ die("last-modified: bad revision '%s'", arg);
+ }
+
+ printf("%lu\n", date);
+
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index df72d09..862cadb 100644
--- a/builtin.h
+++ b/builtin.h
@@ -75,5 +75,6 @@ extern int cmd_write_tree(int argc, const char **argv, const char *prefix);
extern int cmd_verify_pack(int argc, const char **argv, const char *prefix);
extern int cmd_show_ref(int argc, const char **argv, const char *prefix);
extern int cmd_pack_refs(int argc, const char **argv, const char *prefix);
+extern int cmd_last_modified(int argc, const char **argv, const char *prefix);
#endif
diff --git a/git.c b/git.c
index c82ca45..e6242e6 100644
--- a/git.c
+++ b/git.c
@@ -269,6 +269,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
{ "verify-pack", cmd_verify_pack },
{ "show-ref", cmd_show_ref, RUN_SETUP },
{ "pack-refs", cmd_pack_refs, RUN_SETUP },
+ { "last-modified", cmd_last_modified, RUN_SETUP },
};
int i;
diff --git a/t/t3810-last-modified.sh b/t/t3810-last-modified.sh
new file mode 100755
index 0000000..d85283e
--- /dev/null
+++ b/t/t3810-last-modified.sh
@@ -0,0 +1,57 @@
+#!/bin/sh
+
+test_description='git-last-modified'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ for n in 1 2 3 4 5 ; do \
+ echo $n > a ; \
+ git-add a ; \
+ git-commit -m "$n" ; \
+ done ; \
+ git-tag -m "t1" t1 ; \
+ git-checkout -b o ; \
+ for n in o1 o1 o3 o4 o5 ; do \
+ echo $n > b ; \
+ git-add b ; \
+ git-commit -m "$n" ; \
+ done ; \
+ git-tag -m "t2" t2 ; \
+ git-checkout master
+'
+
+test_expect_success 'no options' '
+ test $(git-last-modified) -eq 0
+'
+
+test_expect_success 'rev HEAD' '
+ test $(git-last-modified HEAD) -gt 0 &&
+ test $(git-last-modified refs/heads/master) -gt 0 &&
+ test $(git-last-modified --all) -gt 0 &&
+ test $(git-last-modified --branches) -gt 0 &&
+ test $(git-last-modified --tags) -gt 0 &&
+ test $(git-last-modified --remotes) -eq 0
+'
+
+test_expect_success 'rev master -lt o' '
+ test $(git-last-modified master) -lt $(git-last-modified o)
+'
+
+test_expect_success 'mixed --branches HEAD t1 o' '
+ test $(git-last-modified --branches HEAD t1 o) -gt 0
+'
+
+test_expect_failure 'bad sha1' '
+ git-last-modified 000000
+'
+
+test_expect_failure 'bad rev' '
+ git-last-modified xyz
+'
+
+test_expect_failure 'bad --branches rev' '
+ git-last-modified xyz
+'
+
+test_done
--
1.5.0.rc0.g2708-dirty
^ permalink raw reply related
* Re: http git and curl 7.16.0
From: Junio C Hamano @ 2007-01-01 8:08 UTC (permalink / raw)
To: George Sherwood; +Cc: Horst H. von Brand, Nick Hengeveld, skimo, git
In-Reply-To: <20070101114252.6a76269e@athlon>
George Sherwood <pilot@beernabeer.com> writes:
> I CC'ed the mailing curl mailing list and according to the response
> this problem is fixed in the latest cvs version of curl with this
> commit:
>
> curl_easy_duphandle() sets the magic number in the new handle
>
> I have confirmed this works now git 1.4.4.3
Thanks, so it was a breakage on the .0 release on their side.
I'll leave this in place for now:
#if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBCURL_VERSION_NUM == 0x071000)
#define NO_CURL_EASY_DUPHANDLE
#endif
which specifically marks 7.16.0 as dud.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-01 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce, Johannes Schindelin, J. Bruce Fields
In-Reply-To: <7vfyav8ae1.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > --- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > ...
> >> Could you explain a situation where this would be useful?
> >
> > I don't know how to respond to this question.
> >
> >> A
> >> "parent<-->child" relationship, where there's one upstream branch that
> >> is always merged in, is easily handled;
> >
> > e is the base of natural logarithms.
>
> You lost me here; I am guessing this is some sarcasm not worth
> paying attention to, so I'd ignore this part for now.
Absolutely correct. I just needed to respond to an obvious fact with
another obvious fact.
> >> just replace your "git pull parent" by a "git pull", right?
> >
> > Yes, but I don't want to just type "git-pull", I want to explicitly
> > type "git-pull parent" and depending in which branch I'm at, "parent"
> > would have identical meaning but would merge a different branch... because
> > I'm in a different branch...
> >
> >> Am I misunderstanding the proposal?
> >
> > I did give an example of usage in my email to which you replied.
>
> But what confuses me (and I think JBF shares the same confusion
> with me) is that you had only one example "parent".
More complicated and exotic examples exist. See my response
to JBF, which I just posted a moment ago.
> While I understand that it would make sense to define "parent"
No, no, no. Forget about the semantic attibute of "parent".
I could've called it "xyz" for that matter.
What I'm talking about is the concept of "branch spec". It
is a well known concept in SCMs.
We currently implement it, in git specific way, for remotes/
only, but not for local ("topic") branches.
Another way to look at it is that a Topic, can have many
other self-contained sub-Topics, each one building on the one
"before" it, extending it, yet introducing new functionality,
and only in the "leaf" branch, do you get a fully capable software.
Each sub-topic branch is also a working software but only implements
part of the functionality of your product and/or toned down version
of it, say if someone doesn't want support for feature ABC, which
uses 100MiB of memory...
> for each branch in a downstream developer's workflow, (1) I do
> not see the difference between your wording, "parent", and what
> we traditionally have called "origin",
I've always contended that it is the same and had mentioned
that it is only implemented for remotes/.
> and (2) I do not think of
> relationship other than "parent" ("origin") that is applicable
> commonly (in other words, "worth having your 'symbolic'
> mechanism for, because it is so commonly applicable") to
> branches offhand. Hence, JBF's suggestion to use "git pull"
> without using noiseword "parent" or "origin" feels very natural
> to me --- if there can be only one valid thing to say, why do
> you even have to say it?
Well, this is the question... Can you stipulate that there is
only _one_ valid thing to say? Wouldn't it be easier to generalize
the concept of "branch spec" to local "topic" branches as we do
now for remotes/. Wouldn't this allow people to have more freedom
at what and how they'd like to set their software dependencies?
The SCM industry seem to have generalized this with the
concept of a "branch spec".
> Because I do not understand what you would want "parent" for and
> why "git pull" is not sufficient,
Because it _implicitly_ defines the relationship. Nothing wrong
with that, but also allowing an explicit naming of the relationship,
as is currently done for remotes/, would give git much, much more
power to define even the most complicated software development
setup (locally).
As I pointed out before, "branch.<name>..{fetch,merge}" would
cover the "git-pull" case. "branch..<symbolic-ref>.{fetch,merge}"
should be illegal since it is the same as remotes/, and
"branch.<name>.<symbolic-ref>.{fetch, merge}" matches
"git-pull <symbolic-ref>".
> I cannot tell if this would
> help solving what you are trying to solve in a different way,
1) It would help solve it the proper way and,
2) it would give git the concept of "branch spec" universally, i.e.
local branches as well as remotes.
> but I suspect a useful thing to have might be a per-branch
> alias. For example, we could allow "git merge" without
> parameters to alias to "git merge origin/next" when you are on
> your 'next' and the same "git merge" could be aliased to "git
> merge origin/master" when you are on your 'master'.
Any why not solve the absolute general case forever, by
implementing what I have described above, and move on
to more interesting things?
Luben
^ permalink raw reply
* Re: RFC: working with sparse work-copy: where to start?
From: Michael S. Tsirkin @ 2007-01-01 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodpjdekh.fsf@assigned-by-dhcp.cox.net>
> > Hi!
> > I've been thinking about working in a sparsely-populated work copy.
> > E.g. svn will let you do a checkout of a specific sub-directory
> > and do all your development there assuming you only care about
> > changes in that directory. Ideally, it would be possible to specify
> > a set of directories that I care about.
> > ...
> > What other commands need to be fixed for this to work?
>
> Pretty much everything needs to be changed, I suspect.
>
> The point of git is to track the whole tree, and that is
> ingrained to the design of the tool everywhere. You need to
> bend backwards to operate in the way you propose; I am not
> saying it is impossible but I suspect it will be very hard or
> inefficient or both.
>
> Your commits, although your working tree will only have selected
> subtrees in "wrong" places, should have the same "directory
> structure" as everybody else. This is an absolute requirement
> for the result of your work in your repository to be usable by
> others.
>
> One design level thing you need to worry about is what to do
> with merges, if you are pulling from more than one people and
> they start their work in different version of "the whole tree".
> You may not be interested in what happens in "other parts" of
> the whole tree you are not checking out. For your merge result
> to be any useful for other people you later want to merge from
> you, you still have to come up with and record the sensible
> result when these "other parts" have conflicts.
Yes, I've been thinking about this problem. As far as the merge can be
done in-index it should be fine though. Maybe failing a merge if there are
merges that can't be done with the checked out subtree is the right thing to do.
But, this means that we should try harder to merge in-index
changes that touch non-checked-out files.
For example, a commit could touch a checked-out and non-checked out file,
and non-checked-out file could be index-mergeable but checked-out one
would need file level merge. Yes?
> This means the tree objects you will create as the final product
> has to have the same directory structure as other people, while
> your working tree will have only selected things, and in "wrong"
> (from the tree's perspective) places.
>
> One decision you need to make early is which side you place your
> index on.
>
> One approach would be to have the same directory structure in
> the index. The other possibility is to match the directory
> structure recorded in the index with the structure of your
> working tree. I am not sure pros-and-cons offhand.
>
> Regardless of which avenue you pursue, you need to have a way to
> tell your version of git which subtree your repository is
> interested in, and where in your working tree you want to check
> them out. And you would need to change affected commands to
> take this new information into account when do their work.
>
> The former approach means you do not have to touch write-tree
> and read-tree, but your diff-index, diff-tree (when you want it
> to work sensibly inside subdirectories), checkout-index and
> update-index need to know about this. The latter means you do
> not have to touch diff-files, update-index and checkout-index,
> but read-tree will be affected. Any command that deals with
> both tree and working directory at the same time (diff-index,
> read-tree -u, merge-recursive, etc.) or works from a
> subdirectory (pretty much all Porcelain commands -- think of
> 'git add .' in a subdirectory) will need to change regardless of
> which approach is taken.
>
> I think it would be a lot simpler if you do not mind deep
> directory structure but still support a sparse checkout,
> though.
OK, I don't mind the deep directory structure so much.
I'm sorry, Junio, but I'm a bit lost wrt which of your comments
are related to the directory structure change idea
(which it seems wise to drop) and which to the sparse checkout
support which might be more doable. Could you help please?
--
MST
^ permalink raw reply
* failed to read delta-pack.
From: Michael S. Tsirkin @ 2007-01-01 9:49 UTC (permalink / raw)
To: git
I'm getting this with git 1.4.4.3:
remote: Generating pack...
remote: Done counting 1294 objects.
remote: Result has 916 objects.
remote: Deltifying 916 objects.
remote: 100% (916/916) done
Unpacking 916 objects
remote: Total 916, written 916 (delta 758), reused 0 (delta 0)
error: failed to read delta-pack base object
b47ceb21cfed93f410e6329040784d43864dab33
fatal: unpack-objects died with error code 1
Fetch failure: /mswg2/git/linux-2.6/.git
--
MST
^ permalink raw reply
* StGIT-0.11: Python exception when removing branch
From: Andrey Borzenkov @ 2007-01-01 12:49 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Every time I try to remove a branch I get:
{pts/0}% stg branch --delete stable
Deleting branch "stable"...
Traceback (most recent call last):
File "/usr/bin/stg", line 43, in <module>
main()
File "/usr/lib/python2.5/site-packages/stgit/main.py", line 261, in main
command.func(parser, options, args)
File "/usr/lib/python2.5/site-packages/stgit/commands/branch.py", line 167,
in func
__delete_branch(args[0], options.force)
File "/usr/lib/python2.5/site-packages/stgit/commands/branch.py", line 107,
in __delete_branch
doomed.delete(force)
File "/usr/lib/python2.5/site-packages/stgit/stack.py", line 583, in delete
if not os.listdir(self.__series_dir):
OSError: [Errno 2] No such file or directory: '.git/patches/stable'
Well, it is correct, stable has never had any patches, but why stg is so upset
about it? :)
The state after this command is
{pts/2}% stg branch -l
Available branches:
> s cooker |
s origin |
stable |
It did not happen before; I am not sure whether it was introdied by StGIT or
Pythn update.
Regards and happy new year
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFmQNMR6LMutpd94wRAuWCAKDQmc5xTW/0okN+MMx5Y8GUBSiqQgCggpUY
fWPjyHx/usyneWVaRl61lZM=
=vnEW
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Theodore Tso @ 2007-01-01 13:17 UTC (permalink / raw)
To: Luben Tuikov
Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin,
J. Bruce Fields
In-Reply-To: <997672.38239.qm@web31814.mail.mud.yahoo.com>
Luben,
Let me see if I can understand what you are asking for without using
the term "branch spec", which I don't think has been adequately
defined yet in this thread. (Where "the SCM industry has adopted"
isn't a definition. :-)
Currently, today, if you type:
git fetch <non-URL>
... it will look up "<non-URL>" in a single global namespace, which
(using only the new config scheme) is looked up in remote.<non-URL>
and remote.<non-URL>.{url,fetch} is used to control the operation of
git-fetch.
What you want to do is to change this to where:
git fetch <non-URL>
...will now lookup "<non-URL>" in a namespace which is qualified by
the branch that you are in. So you want to look up the information in
branches.<current-branch>.<non-URL>.{url,fetch} instead.
You haven't stated it explicitly, but I assume that if
branches.<current-branch>.<non-URL> doesn't exist, you're proposing
that the code fall back to looking in the old configuration parameter,
remote.<non-URL>, so that certain names that should be global can
continue to be global, and that people who want a single global
namespace can continue to have it?
Is that your proposal, stripped of the arguments of why you want it,
and of the somewhat confusing "parent" example (which is a bad one
given that your "git pull parent" example was the semantic equivalent
of "git pull")?
If it is, I'm a bit nervous since it's making the git-fetch command
modal, and modal UI's are confusing to users. On the other hand, it's
a fundamental modality we have already (based on the question "which
branch am I"), and there are hacks that will allow you to put the
current branch into your command-line. And as long as you are
proposing a lookup in branches.current.branch.<non-URL> first before
checking remotes.<non-URL> it seems mostly harmless to me. I doubt
I'd ever use it, but maybe it would be helpful to some.
- Ted
^ permalink raw reply
* i18n, alternative solution
From: Robin Rosenberg @ 2007-01-01 14:47 UTC (permalink / raw)
To: git
Hi and Happy New Year
Things are happening wrt to support for working with multiple locales, which
is nice to see. I've not had time to follow the development so these comments
(and code) may be considered somewhat late in the process.
What disturbes me is the complexity that the approach of storing multiple
encodings in the same repository results in. I was hacking another solution
earlier this autumn, that takes another approach, i.e. UTF-8 is the internal
encoding. period. If you want to working with anything else, you convert on
input and output. The code is very simply since it has few cases to consider
and I don' t need to store encoding anywhere. What is missing is a flags to
disable i18n for a flag (or enable it).
The uglyness is the filename parts since I catch all filename operations and
not only the ones I need. The target wasn't final code, but to prove that it
could be done.
The focus is on file names, but commit messages were included since it was so
simple. You can get the code at http://rosenberg.homelinux.net/repos/GIT.git
on the branch i18n. I modded the testcases to verify that GIT works after the
patches, but one would probably prefer to write new test cases for UTF-8.
5d73e28397f7ec0f85fcb8e31e91326afbcfea19 is the last commit that executes all
test cases successfully.
I could send the code as patches if you like, not on top of the lastest
version though, but 1.4.2-something,
-- robin
^ permalink raw reply
* Re: i18n, alternative solution
From: Junio C Hamano @ 2007-01-01 19:44 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200701011547.48697.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> What disturbes me is the complexity that the approach of storing multiple
> encodings in the same repository results in.
We are not encouraging mixed encodings, mind you.
Even though we check and warn comits that do not have a valid
UTF-8 string, the users can make mistakes and people need be
able to look at them later. That is what we are solving.
At the same time we do NOT force inconvenience on projects that
want to use legacy encoding for whatever reason. The world is
not UTF-8 only, and encoding to UTF-8 is non-reversible a times
(positive return value from iconv(3)). Always re-coding to
UTF-8 will NOT be accepted to git for now. We can revisit this
perhaps in 5 years.
^ permalink raw reply
* [PATCH] git-fetch: remove .keep file even on other errors.
From: Junio C Hamano @ 2007-01-01 20:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612282031390.18171@xanadu.home>
Actually removal of them is needed especially on errors. The
original code had the removal outside of the process which sets
the flag to tell the later step what to remove, but it runs as a
downstream of a pipeline and its effect was lost.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Nicolas Pitre <nico@cam.org> writes:
> [ resuming an old thread ]
Likewise... This should fix it, I think.
git-fetch.sh | 23 ++++++++++++++++-------
1 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index 8bd11f8..466fe59 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -382,13 +382,22 @@ fetch_main () {
;; # we are already done.
*)
( : subshell because we muck with IFS
- pack_lockfile=
IFS=" $LF"
(
- git-fetch-pack --thin $exec $keep $shallow_depth "$remote" $rref || echo failed "$remote"
+ git-fetch-pack --thin $exec $keep $shallow_depth "$remote" $rref ||
+ echo failed "$remote"
) |
- while read sha1 remote_name
- do
+ (
+ trap '
+ if test -n "$keepfile" && test -f "$keepfile"
+ then
+ rm -f "$keepfile"
+ fi
+ ' 0
+
+ keepfile=
+ while read sha1 remote_name
+ do
case "$sha1" in
failed)
echo >&2 "Fetch failure: $remote"
@@ -397,7 +406,7 @@ fetch_main () {
pack)
continue ;;
keep)
- pack_lockfile="$GIT_OBJECT_DIRECTORY/pack/pack-$remote_name.keep"
+ keepfile="$GIT_OBJECT_DIRECTORY/pack/pack-$remote_name.keep"
continue ;;
esac
found=
@@ -429,8 +438,8 @@ fetch_main () {
append_fetch_head "$sha1" "$remote" \
"$remote_name" "$remote_nick" "$local_name" \
"$not_for_merge" || exit
- done &&
- if [ "$pack_lockfile" ]; then rm -f "$pack_lockfile"; fi
+ done
+ )
) || exit ;;
esac
--
1.5.0.rc0.ga105
^ permalink raw reply related
* Re: [RFC/PATCH] fail pull/merge early in the middle of conflicted merge
From: Shawn O. Pearce @ 2007-01-01 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt478b5d.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> After a pull that results in a conflicted merge, a new user
> often tries another "git pull" in desperation. When the index
> is unmerged, merge backends correctly bail out without touching
> either index nor the working tree, so this does not make the
> wound any worse.
I've seen this many times too. I don't understand why users cannot
read output messages and realize the current command failed, but
they don't. *sigh*
> Old timers may know better and would not to try pulling again
> before cleaning things up; this change adds extra overhead that
> is unnecessary for them. But this would be worth paying for to
> save new people from needless confusion.
This penalty isn't very high though; its just a single pass through
the index to look for an unmerged entry. I think that small
penalty is worth the better error message here, and that's the guy
who just submitted patches to remove other penalties in pull and
merge talking. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/4] Automatically detect a bare git repository.
From: Shawn O. Pearce @ 2007-01-01 20:57 UTC (permalink / raw)
To: Martin Waitz; +Cc: Junio C Hamano, git
In-Reply-To: <20061231175407.GC6115@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
> On Sat, Dec 30, 2006 at 11:30:19PM -0500, Shawn O. Pearce wrote:
> > We test the current working directory only after we have tried
> > searching up the directory tree. This is to retain backwards
> > compatibility with our previous behavior on the off chance that
> > a user has a 'refs' and 'objects' subdirectories and a 'HEAD'
> > file that looks like a symref, all stored within a repository's
> > associated working directory.
>
> Hmm, I have my dot files under GIT control so I can't use this mechanism
> to use bare GIT repositories under ~/git/*.git.
Whoops. I assume you have your .gitignore populated with the other
files/directories in your home directory that shouldn't be under
Git control?
> Perhaps we should test the current directory first, but check that it
> ends in .git?
Junio already stated why that may not be a good idea. My original
version of the patch did check the current directory first, but it
could match a working directory which isn't really a Git repository
but just looks sort of like one.
That wouldn't be backwards compatible, so I moved the current
directory check to just before failure. That version is the one
that I submitted, and that Junio accepted...
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/4] Automatically detect a bare git repository.
From: Shawn O. Pearce @ 2007-01-01 21:01 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, git
In-Reply-To: <20061231125205.GB14286@thunk.org>
Theodore Tso <tytso@mit.edu> wrote:
> On Sat, Dec 30, 2006 at 11:30:19PM -0500, Shawn O. Pearce wrote:
> > Many users find it unfriendly that they can create a bare git
> > repository easily with `git clone --bare` but are then unable to
> > run simple commands like `git log` once they cd into that newly
> > created bare repository. This occurs because we do not check to
> > see if the current working directory is a git repository.
>
> Thanks for coding this up!
>
> If you do this, does this mean that we can also eliminate the global
> variable --bare, since git will be able to figure out we're in a bare
> repository all by itself?
Probably not. `git --bare foo` is a Poreclain-ish level option
which has been supported for several versions. Removing it may
cause pain for users to retrain their fingers to just ignore it.
Besides `git --bare` can be used in cases where the bare Git
repository is actually located within another repository's working
directory and the automatic detection is picking up the other
repository's metadata and not the bare repository's metadata.
So I think --bare is still here to stay for a while. The new
automatic detection just offers slightly less surprise for users.
--
Shawn.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Shawn O. Pearce @ 2007-01-01 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcvcfpze.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> * sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
>
> This is Shawn's sliding mmap series to allow smaller virtual
> memory footprint to access larger packfiles. I started using
> this series in production tonight. Although the size of the
> series is somewhat intimidating, they are sane changes and I
> think it may be worth considering for 'master'. This does not
> change the user experience majorly as has almost no UI elements,
> so it could go in either before or after v1.5.0.
I know your testing is saying this series may be slightly faster than
the prior code in 'master', and at least on Linux can be so without
using a lot of virtual address space as mmap() is so fast there.
(Nice job kernel people!) Anyway, I haven't done any performance
testing on this myself. It would be nice to know more about how
it behaves.
> * sp/merge (Sun Dec 31 00:02:13 2006 -0500) 6 commits
> - Refresh the index before starting merge-recursive.
> - Improve merge performance by avoiding in-index merges.
> - Avoid git-fetch in `git-pull .` when possible.
> + Use merge-recursive in git-am -3.
> + Allow merging bare trees in merge-recursive.
> + Move better_branch_name above get_ref in merge-recursive.
>
> I'm reasonably happy with the earlier three of this series but
> not really about the latter, and I've already described why.
I know you've stated a number of good reasons against "Avoid
git-fetch in `git-pull .` when possible.". One way I've thought
of trying to resolve that would be to verify the arguments to
`git pull .` are refs only (and not SHA1 expressions) which makes
the behavior the same as `git pull .` and *might* still save time,
as the fetch can still get bypassed.
The only objection I know of to "Improve merge performance by
avoiding in-index merges." was that it needs more testing to ensure
its doing the same thing as before, which basically means we hold it
out until post v1.5.0. Since it is only a performance improvement
I think that's reasonable.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: J. Bruce Fields @ 2007-01-01 21:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce, Luben Tuikov, Johannes Schindelin
In-Reply-To: <7vwt47bjwa.fsf@assigned-by-dhcp.cox.net>
On Sun, Dec 31, 2006 at 05:44:37PM -0800, Junio C Hamano wrote:
> How about doing this? The difference this time around is that
> if you have non-wildcard refspec listed first, which usually
> is the case for people with established git workflow with
> existing repositories, we use the old-and-proven rule to
> merge the first set of refs. An earlier round botched this
> completely by basing the logic on lack of branch.*.merge,
> which broke for many people.
Updated man page assuming that change; does this look any better?
--b.
[PATCH] Documentation: update git-pull.txt for new clone behavior
Update examples, stop using branch named "origin" as an example.
Remove large example of use of remotes; that particular case is
nicely automated by default, so it's not so pressing to explain, and
we can refer to git-repo-config for the details.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/git-pull.txt | 69 ++++++++++++++++----------------------------
1 files changed, 25 insertions(+), 44 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 2a5aea7..13be992 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -37,17 +37,27 @@ EXAMPLES
--------
git pull, git pull origin::
- Fetch the default head from the repository you cloned
- from and merge it into your current branch.
-
-git pull -s ours . obsolete::
- Merge local branch `obsolete` into the current branch,
- using `ours` merge strategy.
+ Update the remote-tracking branches for the repository
+ you cloned from, then merge one of them into your
+ current branch. Normally the branch merged in is
+ the HEAD of the remote repository, but the choice is
+ determined by the branch.<name>.remote and
+ branch.<name>.merge options; see gitlink:git-repo-config[1]
+ for details.
+
+git pull origin next::
+ Merge into the current branch the remote branch `next`;
+ leaves a copy of `next` temporarily in FETCH_HEAD, but
+ does not update any remote-tracking branches.
git pull . fixes enhancements::
Bundle local branch `fixes` and `enhancements` on top of
the current branch, making an Octopus merge.
+git pull -s ours . obsolete::
+ Merge local branch `obsolete` into the current branch,
+ using `ours` merge strategy.
+
git pull --no-commit . maint::
Merge local branch `maint` into the current branch, but
do not make a commit automatically. This can be used
@@ -61,48 +71,19 @@ release/version name would be acceptable.
Command line pull of multiple branches from one repository::
+
------------------------------------------------
-$ cat .git/remotes/origin
-URL: git://git.kernel.org/pub/scm/git/git.git
-Pull: master:origin
-
$ git checkout master
-$ git fetch origin master:origin +pu:pu maint:maint
-$ git pull . origin
+$ git fetch origin +pu:pu maint:tmp
+$ git pull . tmp
------------------------------------------------
+
-Here, a typical `.git/remotes/origin` file from a
-`git-clone` operation is used in combination with
-command line options to `git-fetch` to first update
-multiple branches of the local repository and then
-to merge the remote `origin` branch into the local
-`master` branch. The local `pu` branch is updated
-even if it does not result in a fast forward update.
-Here, the pull can obtain its objects from the local
-repository using `.`, as the previous `git-fetch` is
-known to have already obtained and made available
-all the necessary objects.
-
-
-Pull of multiple branches from one repository using `.git/remotes` file::
+This updates (or creates, as necessary) branches `pu` and `tmp`
+in the local repository by fetching from the branches
+(respectively) `pu` and `maint` from the remote repository.
+
-------------------------------------------------
-$ cat .git/remotes/origin
-URL: git://git.kernel.org/pub/scm/git/git.git
-Pull: master:origin
-Pull: +pu:pu
-Pull: maint:maint
-
-$ git checkout master
-$ git pull origin
-------------------------------------------------
+The `pu` branch will be updated even if it is does not
+fast-forward; the others will not be.
+
-Here, a typical `.git/remotes/origin` file from a
-`git-clone` operation has been hand-modified to include
-the branch-mapping of additional remote and local
-heads directly. A single `git-pull` operation while
-in the `master` branch will fetch multiple heads and
-merge the remote `origin` head into the current,
-local `master` branch.
+The final command then merges the newly fetched `tmp` into master.
If you tried a pull which resulted in a complex conflicts and
@@ -112,7 +93,7 @@ gitlink:git-reset[1].
SEE ALSO
--------
-gitlink:git-fetch[1], gitlink:git-merge[1]
+gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-repo-config[1]
Author
--
1.5.0.rc0.gac28
^ permalink raw reply related
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: J. Bruce Fields @ 2007-01-01 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce, Luben Tuikov, Johannes Schindelin
In-Reply-To: <20070101213906.GA23857@fieldses.org>
On Mon, Jan 01, 2007 at 04:39:06PM -0500, J. Bruce Fields wrote:
> On Sun, Dec 31, 2006 at 05:44:37PM -0800, Junio C Hamano wrote:
> > How about doing this? The difference this time around is that
> > if you have non-wildcard refspec listed first, which usually
> > is the case for people with established git workflow with
> > existing repositories, we use the old-and-proven rule to
> > merge the first set of refs. An earlier round botched this
> > completely by basing the logic on lack of branch.*.merge,
> > which broke for many people.
>
> Updated man page assuming that change; does this look any better?
Also, resend of the following patch:
--b.
[PATCH] Documentation: remove master:origin example from pull-fetch-param.txt
This is no longer a useful example.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/pull-fetch-param.txt | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index e852f41..8d4e950 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -39,10 +39,6 @@ checkout -b my-B remote-B`). Run `git fetch` to keep track of
the progress of the remote side, and when you see something new
on the remote branch, merge it into your development branch with
`git pull . remote-B`, while you are on `my-B` branch.
-The common `Pull: master:origin` mapping of a remote `master`
-branch to a local `origin` branch, which is then merged to a
-local development branch, again typically named `master`, is made
-when you run `git clone` for you to follow this pattern.
+
[NOTE]
There is a difference between listing multiple <refspec>
--
1.5.0.rc0.gac28
^ permalink raw reply related
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-01 23:56 UTC (permalink / raw)
To: Theodore Tso
Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin,
J. Bruce Fields
In-Reply-To: <20070101131726.GA21933@thunk.org>
--- Theodore Tso <tytso@mit.edu> wrote:
> Luben,
>
> Let me see if I can understand what you are asking for without using
> the term "branch spec", which I don't think has been adequately
> defined yet in this thread. (Where "the SCM industry has adopted"
> isn't a definition. :-)
You can also think of it as "the merge direction given a symbolic name".
> Currently, today, if you type:
>
> git fetch <non-URL>
>
> ... it will look up "<non-URL>" in a single global namespace, which
> (using only the new config scheme) is looked up in remote.<non-URL>
> and remote.<non-URL>.{url,fetch} is used to control the operation of
> git-fetch.
I'm talking about more in terms of git-merge, but since git-pull
is a git-fetch and git-merge, I've been using git-pull for completeness.
IOW, I've tried to concentrate on a per-repo operations (merge) as opposed
to on a multi-repo, which is currently handled by git as is expected.
> What you want to do is to change this to where:
>
> git fetch <non-URL>
git-pull, for completeness. See my paragraph above.
> ...will now lookup "<non-URL>" in a namespace which is qualified by
> the branch that you are in. So you want to look up the information in
> branches.<current-branch>.<non-URL>.{url,fetch} instead.
More specifically,
branch.<branch-match>.<symbolic-ref match>.{fetch,merge}.
branch.<branch-match>..{fetch,merge} is allowed and defalts
to already implemented "git-pull".
branch..<symbolic-ref match>.{fetch,merge} is forbidden
since it is essentially remotes/ and is handled by the current
"remotes/" infrastructure by git.
branch.<branch-match>.<symbolic-ref match>.{fetch,merge} will
perform the fetch, which would be a no-op, since the branch
we're "fetching" is local, and the merge merges into the
current branch if it matches.
> You haven't stated it explicitly, but I assume that if
> branches.<current-branch>.<non-URL> doesn't exist, you're proposing
> that the code fall back to looking in the old configuration parameter,
> remote.<non-URL>, so that certain names that should be global can
> continue to be global, and that people who want a single global
> namespace can continue to have it?
Yes, I absolutely do not want to break existing behavior. But
if it is extended, it should be done properly, and a general
case should be solved as to solve this once and forever.
> Is that your proposal, stripped of the arguments of why you want it,
> and of the somewhat confusing "parent" example (which is a bad one
> given that your "git pull parent" example was the semantic equivalent
> of "git pull")?
More or less. Basically, I want local "git-pull" (fetch[no-op],merge)
to be addressable, i.e. _named_, so that I can establish a more complex
software dependency, which I currently do, my means of the order and
the type of "git-pull . <branch>" I do.
> If it is, I'm a bit nervous since it's making the git-fetch command
> modal, and modal UI's are confusing to users.
Think of "git-pull", not just of "git-fetch". As well as think
of a setup where there are more than one branch implementing
software dependency, resolving to a software product.
> On the other hand, it's
> a fundamental modality we have already (based on the question "which
> branch am I"), and there are hacks that will allow you to put the
> current branch into your command-line.
Ah, yes. Well, the many-branches-one-directory is confusing and
is modal. *But*, it doesn't have to be like that. Git allows
the freedom to define branch-per-directory-yet-single-repo which I've
absolutely always used with GIT, and other SCMs. This way it is
absolutely unambiguous "what branch I'm at".
It is in this sense that I do "cd <branch>; git-pull . <branch>"
in a sequence, and I'd rather do "cd <branch>; git-pull <symbolic-ref>"
to define which branch is the merge coming from given the current branch
_and_ the symbolic ref.
> And as long as you are
> proposing a lookup in branches.current.branch.<non-URL> first before
> checking remotes.<non-URL> it seems mostly harmless to me. I doubt
> I'd ever use it, but maybe it would be helpful to some.
Yes, current behavior should absolutely not be broken.
First (<current-branch>,<symbolic-ref>) is matched against
"branch.<name>.<symbolic-ref>.{fetch,merge}" modulo the
cases I've outlined before, and then if everything else
fails, we default to remote/.
Luben
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-01 23:59 UTC (permalink / raw)
To: J. Bruce Fields, Junio C Hamano
Cc: git, Shawn Pearce, Luben Tuikov, Johannes Schindelin
In-Reply-To: <20070101213906.GA23857@fieldses.org>
--- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Sun, Dec 31, 2006 at 05:44:37PM -0800, Junio C Hamano wrote:
> > How about doing this? The difference this time around is that
> > if you have non-wildcard refspec listed first, which usually
> > is the case for people with established git workflow with
> > existing repositories, we use the old-and-proven rule to
> > merge the first set of refs. An earlier round botched this
> > completely by basing the logic on lack of branch.*.merge,
> > which broke for many people.
>
> Updated man page assuming that change; does this look any better?
>
> --b.
>
> [PATCH] Documentation: update git-pull.txt for new clone behavior
>
> Update examples, stop using branch named "origin" as an example.
> Remove large example of use of remotes; that particular case is
> nicely automated by default, so it's not so pressing to explain, and
> we can refer to git-repo-config for the details.
>
> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
> ---
> Documentation/git-pull.txt | 69 ++++++++++++++++----------------------------
> 1 files changed, 25 insertions(+), 44 deletions(-)
>
> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> index 2a5aea7..13be992 100644
> --- a/Documentation/git-pull.txt
> +++ b/Documentation/git-pull.txt
> @@ -37,17 +37,27 @@ EXAMPLES
> --------
>
> git pull, git pull origin::
> - Fetch the default head from the repository you cloned
> - from and merge it into your current branch.
> -
> -git pull -s ours . obsolete::
> - Merge local branch `obsolete` into the current branch,
> - using `ours` merge strategy.
> + Update the remote-tracking branches for the repository
> + you cloned from, then merge one of them into your
> + current branch. Normally the branch merged in is
> + the HEAD of the remote repository, but the choice is
> + determined by the branch.<name>.remote and
> + branch.<name>.merge options; see gitlink:git-repo-config[1]
> + for details.
> +
> +git pull origin next::
No.
> + Merge into the current branch the remote branch `next`;
So, "origin" now means "current branch".
NACK!
Luben
> + leaves a copy of `next` temporarily in FETCH_HEAD, but
> + does not update any remote-tracking branches.
>
> git pull . fixes enhancements::
> Bundle local branch `fixes` and `enhancements` on top of
> the current branch, making an Octopus merge.
>
> +git pull -s ours . obsolete::
> + Merge local branch `obsolete` into the current branch,
> + using `ours` merge strategy.
> +
> git pull --no-commit . maint::
> Merge local branch `maint` into the current branch, but
> do not make a commit automatically. This can be used
> @@ -61,48 +71,19 @@ release/version name would be acceptable.
> Command line pull of multiple branches from one repository::
> +
> ------------------------------------------------
> -$ cat .git/remotes/origin
> -URL: git://git.kernel.org/pub/scm/git/git.git
> -Pull: master:origin
> -
> $ git checkout master
> -$ git fetch origin master:origin +pu:pu maint:maint
> -$ git pull . origin
> +$ git fetch origin +pu:pu maint:tmp
> +$ git pull . tmp
> ------------------------------------------------
> +
> -Here, a typical `.git/remotes/origin` file from a
> -`git-clone` operation is used in combination with
> -command line options to `git-fetch` to first update
> -multiple branches of the local repository and then
> -to merge the remote `origin` branch into the local
> -`master` branch. The local `pu` branch is updated
> -even if it does not result in a fast forward update.
> -Here, the pull can obtain its objects from the local
> -repository using `.`, as the previous `git-fetch` is
> -known to have already obtained and made available
> -all the necessary objects.
> -
> -
> -Pull of multiple branches from one repository using `.git/remotes` file::
> +This updates (or creates, as necessary) branches `pu` and `tmp`
> +in the local repository by fetching from the branches
> +(respectively) `pu` and `maint` from the remote repository.
> +
> -------------------------------------------------
> -$ cat .git/remotes/origin
> -URL: git://git.kernel.org/pub/scm/git/git.git
> -Pull: master:origin
> -Pull: +pu:pu
> -Pull: maint:maint
> -
> -$ git checkout master
> -$ git pull origin
> -------------------------------------------------
> +The `pu` branch will be updated even if it is does not
> +fast-forward; the others will not be.
> +
> -Here, a typical `.git/remotes/origin` file from a
> -`git-clone` operation has been hand-modified to include
> -the branch-mapping of additional remote and local
> -heads directly. A single `git-pull` operation while
> -in the `master` branch will fetch multiple heads and
> -merge the remote `origin` head into the current,
> -local `master` branch.
> +The final command then merges the newly fetched `tmp` into master.
>
>
> If you tried a pull which resulted in a complex conflicts and
> @@ -112,7 +93,7 @@ gitlink:git-reset[1].
>
> SEE ALSO
> --------
> -gitlink:git-fetch[1], gitlink:git-merge[1]
> +gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-repo-config[1]
>
>
> Author
> --
> 1.5.0.rc0.gac28
>
>
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-02 0:01 UTC (permalink / raw)
To: J. Bruce Fields, Junio C Hamano
Cc: git, Shawn Pearce, Luben Tuikov, Johannes Schindelin
In-Reply-To: <20070101214023.GB23857@fieldses.org>
--- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Mon, Jan 01, 2007 at 04:39:06PM -0500, J. Bruce Fields wrote:
> > On Sun, Dec 31, 2006 at 05:44:37PM -0800, Junio C Hamano wrote:
> > > How about doing this? The difference this time around is that
> > > if you have non-wildcard refspec listed first, which usually
> > > is the case for people with established git workflow with
> > > existing repositories, we use the old-and-proven rule to
> > > merge the first set of refs. An earlier round botched this
> > > completely by basing the logic on lack of branch.*.merge,
> > > which broke for many people.
> >
> > Updated man page assuming that change; does this look any better?
>
> Also, resend of the following patch:
>
> --b.
>
> [PATCH] Documentation: remove master:origin example from pull-fetch-param.txt
>
> This is no longer a useful example.
>
> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
> ---
> Documentation/pull-fetch-param.txt | 4 ----
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
> index e852f41..8d4e950 100644
> --- a/Documentation/pull-fetch-param.txt
> +++ b/Documentation/pull-fetch-param.txt
> @@ -39,10 +39,6 @@ checkout -b my-B remote-B`). Run `git fetch` to keep track of
> the progress of the remote side, and when you see something new
> on the remote branch, merge it into your development branch with
> `git pull . remote-B`, while you are on `my-B` branch.
> -The common `Pull: master:origin` mapping of a remote `master`
> -branch to a local `origin` branch, which is then merged to a
> -local development branch, again typically named `master`, is made
> -when you run `git clone` for you to follow this pattern.
So is this no longer the case?
Can someone please bring me up to date?
What is going on?
Luben
> +
> [NOTE]
> There is a difference between listing multiple <refspec>
> --
> 1.5.0.rc0.gac28
>
>
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: J. Bruce Fields @ 2007-01-02 0:06 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin
In-Reply-To: <535252.4420.qm@web31811.mail.mud.yahoo.com>
On Mon, Jan 01, 2007 at 03:59:44PM -0800, Luben Tuikov wrote:
> --- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > +git pull origin next::
>
> No.
>
> > + Merge into the current branch the remote branch `next`;
>
> So, "origin" now means "current branch".
No, "origin" refers to the remote repository that you originally cloned
from.
Pulls always merge into the current branch. So it wouldn't make sense
to specify the current branch on the command line.
--b.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-01-02 0:07 UTC (permalink / raw)
To: git
A happy new year.
I think this is more-or-less it to start the -rc1 cycle.
I'll leave the window open for another week or so before people
come back from the christmas and new year break. I have not
been working on any of the potential changes other people talked
about recently on the list, but things like detached HEAD and
more generic per-branch customization may magically materialize
from somewhere as a robust and usable set of patches.
I also haven't reviewed the introductory documentation set
recently, which I think is necessary before the release.
I'll be sending out an updated draft for v1.5.0 release notes in a
separate message.
* The 'master' branch has these since the last announcement.
Eric Wong (3):
git-svn: remove svnadmin dependency from the tests
git-svn: t/t9100-git-svn-basic: remove old check for NO_SYMLINK
git-svn: t/t91??-*: optimize the tests a bit
J. Bruce Fields (6):
Docs: update cvs-migration.txt to reflect clone's new default behavior
Documentation: update git-clone.txt for clone's new default behavior
Documentation: update glossary entry for "origin"
Documentation: update tutorial's discussion of origin
Documentation: update git-pull.txt for new clone behavior
Documentation: remove master:origin example from pull-fetch-param.txt
Junio C Hamano (12):
send-pack: fix pipeline.
Documentation: illustrate send-pack pipeline.
Update documentation for update hook.
send-pack.c: use is_null_sha1()
send-pack: tell pack-objects to use its internal rev-list.
Do not merge random set of refs out of wildcarded refs
i18n: do not leak 'encoding' header even when we cheat the conversion.
Update send-pack pipeline documentation.
fail pull/merge early in the middle of conflicted merge
git-fetch: remove .keep file at the end.
Strongly discourage --update-head-ok in fetch-options documentation.
Update clone/fetch documentation with --depth (shallow clone) option
Shawn O. Pearce (4):
Move better_branch_name above get_ref in merge-recursive.
Allow merging bare trees in merge-recursive.
Use merge-recursive in git-am -3.
Add test case for update hooks in receive-pack.
Theodore Tso (1):
Fix formatting for urls section of fetch, pull, and push manpages
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-01-02 0:07 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
+ Update packedGit config option documentation.
+ mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
+ pack-objects: fix use of use_pack().
+ Fix random segfaults in pack-objects.
+ Cleanup read_cache_from error handling.
+ Replace mmap with xmmap, better handling MAP_FAILED.
+ Release pack windows before reporting out of memory.
+ Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
+ Test suite for sliding window mmap implementation.
+ Create pack_report() as a debugging aid.
+ Support unmapping windows on 'temporary' packfiles.
+ Improve error message when packfile mmap fails.
+ Ensure core.packedGitWindowSize cannot be less than 2 pages.
+ Load core configuration in git-verify-pack.
+ Fully activate the sliding window pack access.
+ Unmap individual windows rather than entire files.
+ Document why header parsing won't exceed a window.
+ Loop over pack_windows when inflating/accessing data.
+ Replace use_packed_git with window cursors.
+ Refactor how we open pack files to prepare for multiple windows.
+ Create read_or_die utility routine.
+ Use off_t for index and pack file lengths.
+ Refactor packed_git to prepare for sliding mmap windows.
+ Introduce new config option for mmap limit.
+ Replace unpack_entry_gently with unpack_entry.
This is what I was looking at on Cygwin on my wife's box today
(I do not have an easy access to Windows boxes otherwise so my
Cygwin testing is limited to only weekends when I am at home).
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
+ git-merge: preserve and merge local changes when doing fast
forward
Johannes's suggestion to record a tree object instead of
LOCAL_DIFF is roger but not wilco yet --- I haven't thought
through the issue to see an improvement in the suggestion. We
will be clobbering both index and the working tree, and I think
"diff --binary HEAD" and "write-tree" record the equivalent
amount of information given a HEAD for recovery.
* sp/merge (Sun Dec 31 00:02:13 2006 -0500) 3 commits
- Refresh the index before starting merge-recursive.
- Improve merge performance by avoiding in-index merges.
- Avoid git-fetch in `git-pull .` when possible.
Three patches in the earlier part of this series have graduated
to 'master' as I think they are useful.
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
- git-explain
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
- gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
- blame: --show-stats for easier optimization work.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
+ git-diff/git-apply: make diff output a bit friendlier to GNU patch
(part 2)
These are on hold.
^ 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