* Re: Workflow question
From: Junio C Hamano @ 2007-09-26 5:29 UTC (permalink / raw)
To: Russ Brown; +Cc: Jeff King, git
In-Reply-To: <46F9CA2A.7000107@gmail.com>
Russ Brown <pickscrape@gmail.com> writes:
> I'm just wondering at this point why git lets you checkout remote
> tracking branches if it's something you really shouldn't do. Unless it's
> something you want to be able to do in edge cases to fix screwups maybe?
You actually never checkout "remote tracking branches".
You can be in two states, either you are on a branch (meaning,
if you create a commit, the new commit will have the current tip
commit of that branch as its first parent and will become the
new tip commit of that branch), or you aren't on _any_ branch.
The latter state is often affectionately called "detached HEAD"
state.
This is primarily useful for sightseeing. Sometimes people
would want to check out a commit that is not a tip of any
branch. The most typical one is "I want to have a checkout of
version 2.6.17", and people call that (loosely) as "checking out
a tag". In the same way, you can "checkout a remote tracking
branch" (but if you want to be anal in terminology, you never
"check out a tag" nor "check out a remote branch"---you are
detaching your HEAD at the named commit (which could be the one
pointed at by the tag, or the one at the tip of your remote
tracking branch).
Detached HEAD state allows you to make further commits and
merges. Because git allows you to create a new branch from the
current commit (i.e. whatever HEAD points at, be it on any
branch or detached) without losing local changes in the index
nor the work tree, this is often handy for doing quick fixups and
experiments --- you first start on detached HEAD and if it turns
out not to be so "quick" fixup, at that point you can create a
real branch so that you can continue working on it without
losing track.
> Thanks for this, it's very useful to read examples of workflows in
> actual use. In fact, I was thinking the other day that it would be good
> to have a site that acts as a directory of many different workflows,
> including descriptions of how they work, how you actually go about
> setting it up and using it day to day (i.e. lists of commands for each
> role/task) and the pros/cons that it provides. I reckon that would help
> newbies out quite a bit (if only for the examples). I've seen a few
> individual examples of workflow but nothing like a comprehensive set of
> them.
"Everyday" might be a good starting point for catalogs of
workflows for people playing various roles.
^ permalink raw reply
* [PATCH] core-tutorial: correct URL
From: Randy Dunlap @ 2007-09-26 5:02 UTC (permalink / raw)
To: git; +Cc: junkio
From: Randy Dunlap <rdunlap@xenotime.net>
The tinyurl is incorrect -- it attempts to go to groups.osdl.org,
which is gone. Either use the full URL (in patch) or create a new
tinyurl for this URL.
Is the web page (where I first saw this problem) generated from
this txt file?
http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html
If not, it needs to be updated also.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
Documentation/core-tutorial.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- git-1.5.1.orig/Documentation/core-tutorial.txt
+++ git-1.5.1/Documentation/core-tutorial.txt
@@ -1470,7 +1470,8 @@ Although git is a truly distributed syst
convenient to organize your project with an informal hierarchy
of developers. Linux kernel development is run this way. There
is a nice illustration (page 17, "Merges to Mainline") in
-link:http://tinyurl.com/a2jdg[Randy Dunlap's presentation].
+link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf
+[Randy Dunlap's presentation].
It should be stressed that this hierarchy is purely *informal*.
There is nothing fundamental in git that enforces the "chain of
^ permalink raw reply
* [PATCH] Fix spelling of overridden in documentation
From: Shawn Bohrer @ 2007-09-26 4:12 UTC (permalink / raw)
To: git; +Cc: gitster, Shawn Bohrer
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
---
Documentation/git-merge.txt | 2 +-
Documentation/gitignore.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 144bc16..eae49c4 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -56,7 +56,7 @@ merge.verbosity::
message if conflicts were detected. Level 1 outputs only
conflicts, 2 outputs conflicts and file changes. Level 5 and
above outputs debugging information. The default is level 2.
- Can be overriden by 'GIT_MERGE_VERBOSITY' environment variable.
+ Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
HOW MERGE WORKS
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 9c83095..e8b8581 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -26,7 +26,7 @@ precedence, the last matching pattern decides the outcome):
* Patterns read from a `.gitignore` file in the same directory
as the path, or in any parent directory, with patterns in the
- higher level files (up to the root) being overriden by those in
+ higher level files (up to the root) being overridden by those in
lower level files down to the directory containing the file.
These patterns match relative to the location of the
`.gitignore` file. A project normally includes such
--
1.5.3.GIT
^ permalink raw reply related
* Re: Workflow question
From: Russ Brown @ 2007-09-26 2:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070926004734.GA22617@segfault.peff.net>
Jeff King wrote:
> On Tue, Sep 25, 2007 at 03:56:56PM -0500, Russ Brown wrote:
>
>> I keep reading things similar to this and bit by bit I'm starting to get
>> it. :) I suppose this is one case in which it's definitely a
>> disadvantage to have a good understanding of svn before coming to git...
>>
>> <yoda>You must unlearn what you have learned</yoda>
>
> I prefer to think of it like a war movie, where I keep having
> nightmarish flashbacks to CVS.
>
> But yes, from the outside git _looks_ a lot like other SCMs you may have
> used, and so it's tempting to keep their mental models. But that can
> easily end up being confusing, as you have found. Personally, I think it
> pays to learn a little about what's going on under the hood, and then
> all of the commands Just Make Sense.
>
> There are several explanations floating around; this is a pretty concise
> one:
>
> http://eagain.net/articles/git-for-computer-scientists/
>
Yes, this is very helpful indeed: thank you for that. /me bookmarks. I
hadn't actually realised that rebase creates new commits and replaces
your old ones: I'd thought they just got 'moved' (dunno how I thought it
worked though!)
>> If you delete a branch that has commits on it that aren't referenced by
>> any other branches, will those commits be removed by something like git
>> pack or git gc?
>
> The 'git-prune' command will do this, though it is not run as part of
> git-gc unless you specify --prune.
>
Another thing makes sense now (helped by the link above also).
>> I suppose what has me the most confused is how a developer works with a
>> remote branch: I've come to understand that a developer should never
>> check out and work on a remote branch, and always create a local one and
>> work on that. If he does that using the above hierarchy, there then
>> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is
>> is possible for a developer to work directory on a remote branch?
>
> As Junio noted, you can't, because they're remote. What you have in your
> local repository is a remote _tracking branch_, which is a local ref
> that tracks your idea of what the remote's branches are. And git will
> feel free to overwrite the contents of that tracking branch whenever you
> do a fetch or pull. So if you make commits on it, they are subject to
> being overwritten (and we note this property of the refs by putting them
> in the refs/remotes hierarchy, rather than refs/heads).
>
> So in the case of our developer Jeff, his local repository will have a
> "projectX/featureY" branch that he works on. And he will also have a
> remote tracking branch "origin/projectX/featureY" which indicates where
> his local repo thinks the remote repo points. And the remote repo will
> have a "projectX/featureY" branch, of course.
>
I'm just wondering at this point why git lets you checkout remote
tracking branches if it's something you really shouldn't do. Unless it's
something you want to be able to do in edge cases to fix screwups maybe?
>> Ah,I see... The light is beginning to come on somewhat here, though it's
>> dimmed somewhat by the remote/local branch confusion I mention above,
>> which tends to imply that rebase is only really useful in local branches
>> since it is always the outer-most branch (assuming that my understanding
>> on that is correct, which it may well not be).
>
> Yes, although the important distinction is not so much "this is a local
> branch" but rather "this is a _published_ branch" which implies that
> other people are looking at (and possibly basing work on) it.
>
>> I actually quite like the idea of the freezing before re-basing in the
>> sub-branches. However, to answer the question of which merge strategy
>> would work best for us I think I need to actually set this up and have a
>> play with it to see how it all pans out using the various options available.
>
> Yes, it is easy to get into academic discussions of setups, but in
> practice you need to find a workflow that is smooth for your team.
>
> On one web-based project I work on, we have a setup like this (which is
> very centralized):
>
> - a central repo resides on a development server with two branches,
> "master" and "production"
> - each developer clones the repo with a working tree
> - some developers develop directly on 'master' if they have small
> changes, or only work on one thing at a time; other developers use
> topic branches to work on simultaneous changes
> - any developer can push to master; it is expected that your code is
> in a reasonable state, since it will now be consumed by other
> developers. Anything that has made it into master is considered
> published and should not be rebased. It is up to developers whether
> they want to rebase their work before publishing or to simply merge.
> - some developers communicate directly with each other: "hey, check
> out branch 'foo' in my repo" or "what do you think of this patch?"
> - The live site has a repo cloned from the central repo, pointing at
> "production".
> - there is a test site with a repo cloned from the master.
> Occasionally the master branch is pulled and tested. If it passes,
> it is pushed to the "production" branch. In addition, small
> immediate fixes can go onto "production", tested, and then pushed to
> the central repo's "production"
>
> So this is not necessarily using the distributed nature of that much,
> but it allows those developers who aren't very comfortable with SCMs to
> stick to a "pull, hack, push" workflow. And those who want to can do
> more interesting things if it helps them.
>
Thanks for this, it's very useful to read examples of workflows in
actual use. In fact, I was thinking the other day that it would be good
to have a site that acts as a directory of many different workflows,
including descriptions of how they work, how you actually go about
setting it up and using it day to day (i.e. lists of commands for each
role/task) and the pros/cons that it provides. I reckon that would help
newbies out quite a bit (if only for the examples). I've seen a few
individual examples of workflow but nothing like a comprehensive set of
them.
> -Peff
Thanks!
--
Russ
^ permalink raw reply
* [StGit PATCH 2/2] Test the new powers of "stg assimilate"
From: Karl Hasselström @ 2007-09-26 2:15 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Karl Hasselström
In-Reply-To: <20070926020911.1202.2580.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t1302-assimilate-interop.sh | 59 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 59 insertions(+), 0 deletions(-)
create mode 100755 t/t1302-assimilate-interop.sh
diff --git a/t/t1302-assimilate-interop.sh b/t/t1302-assimilate-interop.sh
new file mode 100755
index 0000000..31f8b78
--- /dev/null
+++ b/t/t1302-assimilate-interop.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+test_description='Test git/StGit interoperability with "stg assimilate"'
+. ./test-lib.sh
+
+test_expect_success 'Create some git-only history' '
+ echo foo > foo.txt &&
+ git add foo.txt &&
+ git commit -a -m foo &&
+ git tag foo-tag &&
+ for i in 0 1 2 3 4; do
+ echo foo$i >> foo.txt &&
+ git commit -a -m foo$i;
+ done
+'
+
+test_expect_success 'Initialize the StGit repository' '
+ stg init
+'
+
+test_expect_success 'Create five patches' '
+ for i in 0 1 2 3 4; do
+ stg new p$i -m p$i;
+ done &&
+ [ "$(echo $(stg applied))" = "p0 p1 p2 p3 p4" ] &&
+ [ "$(echo $(stg unapplied))" = "" ]
+'
+
+test_expect_success 'Pop two patches with git-reset' '
+ git reset --hard HEAD~2 &&
+ ! stg refresh &&
+ stg assimilate &&
+ stg refresh &&
+ [ "$(echo $(stg applied))" = "p0 p1 p2" ] &&
+ [ "$(echo $(stg unapplied))" = "p3 p4" ]
+'
+
+test_expect_success 'Create a new patch' '
+ stg new q0 -m q0 &&
+ [ "$(echo $(stg applied))" = "p0 p1 p2 q0" ] &&
+ [ "$(echo $(stg unapplied))" = "p3 p4" ]
+'
+
+test_expect_success 'Go to an unapplied patch with with git-reset' '
+ git reset --hard $(stg id p3) &&
+ ! stg refresh &&
+ stg assimilate &&
+ stg refresh &&
+ [ "$(echo $(stg applied))" = "p0 p1 p2 p3" ] &&
+ [ "$(echo $(stg unapplied))" = "q0 p4" ]
+'
+
+test_expect_success 'Go back to below the stack base with git-reset' '
+ git reset --hard foo-tag &&
+ stg assimilate &&
+ [ "$(echo $(stg applied))" = "" ] &&
+ [ "$(echo $(stg unapplied))" = "p0 p1 p2 p3 q0 p4" ]
+'
+
+test_done
^ permalink raw reply related
* [StGit PATCH 1/2] Teach "stg assimilate" to repair patch reachability
From: Karl Hasselström @ 2007-09-26 2:15 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Karl Hasselström
In-Reply-To: <20070926020911.1202.2580.stgit@yoghurt>
Rewrite "stg assimilate" so that it in addition to assimilating
commits made on top of the patch stack also will rewrite the
applied/unapplied files to reflect reality. A patch is considered to
be applied if it is reachable from HEAD without passing through a
merge, and unreachable otherwise.
Performance is adequate: On my laptop, it takes less than four seconds
to process the Linux tree (with hot caches).
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/assimilate.py | 190 ++++++++++++++++++++++++++++++++----------
stgit/commands/common.py | 6 +
stgit/stack.py | 6 +
t/t1301-assimilate.sh | 12 +--
4 files changed, 157 insertions(+), 57 deletions(-)
diff --git a/stgit/commands/assimilate.py b/stgit/commands/assimilate.py
index c5f4340..ab2264a 100644
--- a/stgit/commands/assimilate.py
+++ b/stgit/commands/assimilate.py
@@ -23,21 +23,80 @@ from optparse import OptionParser, make_option
from stgit.commands.common import *
from stgit.utils import *
from stgit.out import *
+from stgit.run import *
from stgit import stack, git
-help = 'StGIT-ify any GIT commits made on top of your StGIT stack'
+help = 'StGit-ify any git commits made on top of your StGit stack'
usage = """%prog [options]
-If you have made GIT commits on top of your stack of StGIT patches,
-many StGIT commands will refuse to work. This command converts any
-such commits to StGIT patches, preserving their contents.
+"assimilate" will repair three kinds of inconsistencies in your StGit
+stack, all of them caused by using plain git commands on the branch:
-Only GIT commits with exactly one parent can be assimilated; in other
-words, if you have committed a merge on top of your stack, this
-command cannot help you."""
+ 1. If you have made regular git commits on top of your stack of
+ StGit patches, "assimilate" converts them to StGit patches,
+ preserving their contents.
+
+ 2. Merge commits cannot become patches; if you have committed a
+ merge on top of your stack, "assimilate" will simply mark all
+ patches below the merge unapplied, since they are no longer
+ reachable. If this is not what you want, use "git reset" to get
+ rid of the merge and run "assimilate" again.
+
+ 3. The applied patches are supposed to be precisely those that are
+ reachable from the branch head. If you have used e.g. "git reset"
+ to move the head, some applied patches may no longer be
+ reachable, and some unapplied patches may have become reachable.
+ "assimilate" will correct the appliedness of such patches.
+
+Note that these are "inconsistencies", not "errors"; furthermore,
+"assimilate" will repair them reliably. As long as you are satisfied
+with the way "assimilate" handles them, you have no reason to avoid
+causing them in the first place if that is convenient for you."""
options = []
+class Commit(object):
+ def __init__(self, id):
+ self.id = id
+ self.parents = set()
+ self.children = set()
+ self.patch = None
+ self.__commit = None
+ def __get_commit(self):
+ if not self.__commit:
+ self.__commit = git.get_commit(self.id)
+ return self.__commit
+ commit = property(__get_commit)
+ def __str__(self):
+ if self.patch:
+ return '%s (%s)' % (self.id, self.patch)
+ else:
+ return self.id
+ def __repr__(self):
+ return '<%s>' % str(self)
+
+def read_commit_dag(branch):
+ out.start('Reading commit DAG')
+ commits = {}
+ patches = set()
+ for line in Run('git-rev-list', '--parents', '--all').output_lines():
+ cs = line.split()
+ for id in cs:
+ if not id in commits:
+ commits[id] = Commit(id)
+ for id in cs[1:]:
+ commits[cs[0]].parents.add(commits[id])
+ commits[id].children.add(commits[cs[0]])
+ for line in Run('git-show-ref').output_lines():
+ id, ref = line.split()
+ m = re.match(r'^refs/patches/%s/(.+)$' % branch, ref)
+ if m:
+ c = commits[id]
+ c.patch = m.group(1)
+ patches.add(c)
+ out.done()
+ return commits, patches
+
def func(parser, options, args):
"""Assimilate a number of patches.
"""
@@ -45,49 +104,86 @@ def func(parser, options, args):
def nothing_to_do():
out.info('No commits to assimilate')
- top_patch = crt_series.get_current_patch()
- if not top_patch:
- return nothing_to_do()
+ orig_applied = crt_series.get_applied()
+ orig_unapplied = crt_series.get_unapplied()
- victims = []
- victim = git.get_commit(git.get_head())
- while victim.get_id_hash() != top_patch.get_top():
- victims.append(victim)
- parents = victim.get_parents()
- if not parents:
- raise CmdException, 'Commit %s has no parents, aborting' % victim
- elif len(parents) > 1:
- raise CmdException, 'Commit %s is a merge, aborting' % victim
- victim = git.get_commit(parents[0])
-
- if not victims:
+ # If head == top, we're done.
+ head = git.get_commit(git.get_head()).get_id_hash()
+ top = crt_series.get_current_patch()
+ if top and head == top.get_top():
return nothing_to_do()
if crt_series.get_protected():
raise CmdException(
- 'This branch is protected. Modification is not permitted')
-
- patch2name = {}
- name2patch = {}
-
+ 'This branch is protected. Modification is not permitted.')
+
+ # Find commits to assimilate, and applied patches.
+ commits, patches = read_commit_dag(crt_series.get_name())
+ c = commits[head]
+ patchify = []
+ applied = []
+ while len(c.parents) == 1:
+ parent, = c.parents
+ if c.patch:
+ applied.append(c)
+ elif not applied:
+ patchify.append(c)
+ c = parent
+ applied.reverse()
+ patchify.reverse()
+
+ # Find patches hidden behind a merge.
+ merge = c
+ todo = set([c])
+ seen = set()
+ hidden = set()
+ while todo:
+ c = todo.pop()
+ seen.add(c)
+ todo |= c.parents - seen
+ if c.patch:
+ hidden.add(c)
+ if hidden:
+ out.warn(('%d patch%s are hidden below the merge commit'
+ % (len(hidden), ['es', ''][len(hidden) == 1])),
+ '%s,' % merge.id, 'and will be considered unapplied.')
+
+ # Assimilate any linear sequence of commits on top of a patch.
+ names = set(p.patch for p in patches)
def name_taken(name):
- return name in name2patch or crt_series.patch_exists(name)
-
- for victim in victims:
- patchname = make_patch_name(victim.get_log(), name_taken)
- patch2name[victim] = patchname
- name2patch[patchname] = victim
-
- victims.reverse()
- for victim in victims:
- out.info('Creating patch "%s" from commit %s'
- % (patch2name[victim], victim))
- aname, amail, adate = name_email_date(victim.get_author())
- cname, cmail, cdate = name_email_date(victim.get_committer())
- crt_series.new_patch(
- patch2name[victim],
- can_edit = False, before_existing = False, commit = False,
- top = victim.get_id_hash(), bottom = victim.get_parent(),
- message = victim.get_log(),
- author_name = aname, author_email = amail, author_date = adate,
- committer_name = cname, committer_email = cmail)
+ return name in names
+ if applied and patchify:
+ out.start('Creating %d new patch%s'
+ % (len(patchify), ['es', ''][len(patchify) == 1]))
+ for p in patchify:
+ name = make_patch_name(p.commit.get_log(), name_taken)
+ out.info('Creating patch %s from commit %s' % (name, p.id))
+ aname, amail, adate = name_email_date(p.commit.get_author())
+ cname, cmail, cdate = name_email_date(p.commit.get_committer())
+ parent, = p.parents
+ crt_series.new_patch(
+ name, can_edit = False, commit = False,
+ top = p.id, bottom = parent.id, message = p.commit.get_log(),
+ author_name = aname, author_email = amail, author_date = adate,
+ committer_name = cname, committer_email = cmail)
+ p.patch = name
+ applied.append(p)
+ names.add(name)
+ out.done()
+
+ # Write the applied/unapplied files.
+ out.start('Checking patch appliedness')
+ applied_name_set = set(p.patch for p in applied)
+ unapplied_names = []
+ for name in orig_applied:
+ if not name in applied_name_set:
+ out.info('%s is now unapplied' % name)
+ unapplied_names.append(name)
+ for name in orig_unapplied:
+ if name in applied_name_set:
+ out.info('%s is now applied' % name)
+ else:
+ unapplied_names.append(name)
+ crt_series.set_applied(p.patch for p in applied)
+ crt_series.set_unapplied(unapplied_names)
+ out.done()
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 8ed47ca..79576fa 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -114,9 +114,9 @@ def check_local_changes():
def check_head_top_equal():
if not crt_series.head_top_equal():
raise CmdException(
- 'HEAD and top are not the same. You probably committed\n'
- ' changes to the tree outside of StGIT. To bring them\n'
- ' into StGIT, use the "assimilate" command')
+"""HEAD and top are not the same. This can happen if you
+ modify a branch with git. The "assimilate" command can
+ fix this situation.""")
def check_conflicts():
if os.path.exists(os.path.join(basedir.get(), 'conflicts')):
diff --git a/stgit/stack.py b/stgit/stack.py
index bd08b35..d889f37 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -509,11 +509,17 @@ class Series(PatchSet):
raise StackException, 'Branch "%s" not initialised' % self.get_name()
return read_strings(self.__applied_file)
+ def set_applied(self, applied):
+ write_strings(self.__applied_file, applied)
+
def get_unapplied(self):
if not os.path.isfile(self.__unapplied_file):
raise StackException, 'Branch "%s" not initialised' % self.get_name()
return read_strings(self.__unapplied_file)
+ def set_unapplied(self, unapplied):
+ write_strings(self.__unapplied_file, unapplied)
+
def get_hidden(self):
if not os.path.isfile(self.__hidden_file):
return []
diff --git a/t/t1301-assimilate.sh b/t/t1301-assimilate.sh
index 906f5bb..7f47c31 100755
--- a/t/t1301-assimilate.sh
+++ b/t/t1301-assimilate.sh
@@ -5,7 +5,7 @@ test_description='Test the assimilate command.'
test_expect_success \
'Assimilate in a non-initialized repository' \
- 'stg assimilate'
+ '! stg assimilate'
test_expect_success \
'Initialize the StGIT repository' \
@@ -75,12 +75,10 @@ test_expect_success \
git pull . br
'
-test_expect_success \
- 'Try (and fail) to assimilate the merge commit' \
- '
+test_expect_success 'Assimilate in the presence of a merge commit' '
[ $(stg applied | wc -l) -eq 5 ] &&
- ! stg assimilate &&
- [ $(stg applied | wc -l) -eq 5 ]
- '
+ stg assimilate &&
+ [ $(stg applied | wc -l) -eq 0 ]
+'
test_done
^ permalink raw reply related
* [StGit PATCH 0/2] "stg assimilate" on steroids
From: Karl Hasselström @ 2007-09-26 2:15 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
This makes "stg assimilate" a whole lot more useful, and replaces my
DAG appliedness series. (If you have been using that, manually change
the stack format version back to 2, and create empty "applied" and
"unapplied" files, and run the new assimilate. That should fix it. I
hope. I'll be testing it myself tomorrow.)
Here's what assimilate says about itself:
"assimilate" will repair three kinds of inconsistencies in your
StGit stack, all of them caused by using plain git commands on the
branch:
1. If you have made regular git commits on top of your stack of
StGit patches, "assimilate" converts them to StGit patches,
preserving their contents.
2. Merge commits cannot become patches; if you have committed a
merge on top of your stack, "assimilate" will simply mark all
patches below the merge unapplied, since they are no longer
reachable. If this is not what you want, use "git reset" to get
rid of the merge and run "assimilate" again.
3. The applied patches are supposed to be precisely those that are
reachable from the branch head. If you have used e.g. "git
reset" to move the head, some applied patches may no longer be
reachable, and some unapplied patches may have become
reachable. "assimilate" will correct the appliedness of such
patches.
Note that these are "inconsistencies", not "errors"; furthermore,
"assimilate" will repair them reliably. As long as you are satisfied
with the way "assimilate" handles them, you have no reason to avoid
causing them in the first place if that is convenient for you.
---
Karl Hasselström (2):
Test the new powers of "stg assimilate"
Teach "stg assimilate" to repair patch reachability
stgit/commands/assimilate.py | 190 +++++++++++++++++++++++++++++++----------
stgit/commands/common.py | 6 +
stgit/stack.py | 6 +
t/t1301-assimilate.sh | 12 +--
t/t1302-assimilate-interop.sh | 59 +++++++++++++
5 files changed, 216 insertions(+), 57 deletions(-)
create mode 100755 t/t1302-assimilate-interop.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [StGit PATCH] Make Run available in stack.py
From: Karl Hasselström @ 2007-09-26 2:08 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Karl Hasselström
Needed by shortlog(). Apparently, we have no test for this.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
And I have no idea how I could have avoided triggering this for as
long as I have. I mean, I tested this by sending the patch to the
list!
stgit/stack.py | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/stgit/stack.py b/stgit/stack.py
index 746e59b..bd08b35 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -23,6 +23,7 @@ from email.Utils import formatdate
from stgit.utils import *
from stgit.out import *
+from stgit.run import *
from stgit import git, basedir, templates
from stgit.config import config
from shutil import copyfile
^ permalink raw reply related
* Re: Workflow question
From: Karl Hasselström @ 2007-09-26 1:51 UTC (permalink / raw)
To: Jeff King; +Cc: Russ Brown, git
In-Reply-To: <20070926004734.GA22617@segfault.peff.net>
On 2007-09-25 20:47:34 -0400, Jeff King wrote:
> Personally, I think it pays to learn a little about what's going on
> under the hood, and then all of the commands Just Make Sense.
>
> There are several explanations floating around; this is a pretty
> concise one:
>
> http://eagain.net/articles/git-for-computer-scientists/
I agree. Once you understand that history in git is just a DAG of
commits, and that "branches" are just named pointers into this DAG to
help the user remember where to attach new commits, everything starts
to Just Make Sense.
(And FWIW, that article was quite good as I recall.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Add ability to specify SMTP server port when using git-send-email.
From: Johannes Schindelin @ 2007-09-26 1:42 UTC (permalink / raw)
To: Glenn Rempe; +Cc: Junio C Hamano, git
In-Reply-To: <1A0CAB9D-5C99-4FD7-B3AC-9B3161FD8663@rempe.us>
Hi,
On Tue, 25 Sep 2007, Glenn Rempe wrote:
> > * The indentation was horrible. Maybe your tabstop is set
> > incorrectly?
>
> Can you be more detailed on the definition of 'horrible'? :-) I am using
> Textmate on OS X with soft tab stops (2 spaces). What should it be to
> look less horrible on your end? Or is the issue that I indent fewer
> tabstops than you expect? If so, sorry since perl is not my usual
> language and Ruby 2 space (soft tab) indentation looks right to my eye.
We use soft tabs, with the standard up-to 8 spaces, so that short sighted
people like me can still see that the line is actually indented.
In related news, I just saw that we never mention the 80 characters per
line convention in code, or the 76 characters per line for commit messages
(because of the 4 space indent git-log does -- ouch ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Create .dotest-merge after validating options.
From: Johannes Schindelin @ 2007-09-26 1:38 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1190770213-8651-1-git-send-email-kraai@ftbfs.org>
Hi,
On Tue, 25 Sep 2007, Matt Kraai wrote:
> Creating .dotest-merge before validating the options prevents both
> --continue and --interactive from working if the options are invalid, so
> only create it after validating the options.
Looks very reasonable to me.
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Create .dotest-merge after validating options.
From: Matt Kraai @ 2007-09-26 1:30 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
Creating .dotest-merge before validating the options prevents both
--continue and --interactive from working if the options are invalid,
so only create it after validating the options.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
git-rebase--interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 2fa53fd..7466b5a 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -406,7 +406,6 @@ do
require_clean_work_tree
- mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
if test ! -z "$2"
then
output git show-ref --verify --quiet "refs/heads/$2" ||
@@ -418,6 +417,8 @@ do
HEAD=$(git rev-parse --verify HEAD) || die "No HEAD?"
UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"
+ mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
+
test -z "$ONTO" && ONTO=$UPSTREAM
: > "$DOTEST"/interactive || die "Could not mark as interactive"
--
1.5.3.2
^ permalink raw reply related
* Re: [PATCH] Add ability to specify SMTP server port when using git-send-email.
From: Glenn Rempe @ 2007-09-26 1:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabra2rv3.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 8424 bytes --]
ok, you're the boss! :-)
Comments:
> * As you mentioned, ssmtp plus undocumented "server:port"
> syntax never worked. There is no point supporting the
> combination. Also I do not think it is worth additional
> lines of code to even say "server:port" plus --server-port
> option are not meant to be used together.
ok. I'm new to Git and the project's coding standards. I just
thought that the additional check made the experience friendlier for
the end user in the case of passing ambiguous arguments, even at the
expense of a few lines of code.
> * People who used the undocumented "server:port" syntax did not
> use the new --smtp-server-port option anyway.
Likely true.
>
> * If somebody goes over plain smtp specifies server without
> port, we can let the Net::SMTP to handle the default port.
> No need for _us_ to say that the default is 25.
ok.
> * I do not see much point insisting that port to be numeric; I
> do not know what Net::SMTP accepts, but if it accepts
> my.isp.com:smtp instead of my.isp.com:25, that is fine. This
> has the side effect of keeping people's existing set-up
> working.
ok. Again just trying to protect against invalid arguments.
> * The indentation was horrible. Maybe your tabstop is set
> incorrectly?
Can you be more detailed on the definition of 'horrible'? :-) I am
using Textmate on OS X with soft tab stops (2 spaces). What should
it be to look less horrible on your end? Or is the issue that I
indent fewer tabstops than you expect? If so, sorry since perl is not
my usual language and Ruby 2 space (soft tab) indentation looks right
to my eye.
> * As I am inclined not to insist on numeric port numbers,
> the additional tests become pointless.
ok. Assuming you want to remove the check on port numbers.
> The result is much simpler, and I think it is more readable.
>
Back to my first comment. I agree its more readable with less code.
Just weighing the trade off with user experience. The tool is a bit
'sharper' in the hands of the end user now IMHO.
I hope this was helpful. :-) Its been useful for me in getting to
know Git and the community a bit better. I'll assume you don't need
me to do anything else on this issue? If thats not correct please
let me know.
Glenn
On Sep 25, 2007, at 5:27 PM, Junio C Hamano wrote:
> I'm inclined to do this on top of yours.
>
> * As you mentioned, ssmtp plus undocumented "server:port"
> syntax never worked. There is no point supporting the
> combination. Also I do not think it is worth additional
> lines of code to even say "server:port" plus --server-port
> option are not meant to be used together.
>
> * People who used the undocumented "server:port" syntax did not
> use the new --smtp-server-port option anyway.
>
> * If somebody goes over plain smtp specifies server without
> port, we can let the Net::SMTP to handle the default port.
> No need for _us_ to say that the default is 25.
>
> * I do not see much point insisting that port to be numeric; I
> do not know what Net::SMTP accepts, but if it accepts
> my.isp.com:smtp instead of my.isp.com:25, that is fine. This
> has the side effect of keeping people's existing set-up
> working.
>
> * The indentation was horrible. Maybe your tabstop is set
> incorrectly?
>
> * As I am inclined not to insist on numeric port numbers,
> the additional tests become pointless.
>
> The result is much simpler, and I think it is more readable.
>
> ---
>
> git-send-email.perl | 64 ++++++++++++
> +-----------------------------------
> t/t9001-send-email.sh | 12 ---------
> 2 files changed, 18 insertions(+), 58 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 886f78f..62e1429 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -380,29 +380,6 @@ if (!defined $smtp_server) {
> $smtp_server ||= 'localhost'; # could be 127.0.0.1, too... *shrug*
> }
>
> -# don't allow BOTH forms of port definition to work since we can't
> guess which one is right.
> -if (($smtp_server =~ /:\d+/) && (defined $smtp_server_port)) {
> - die "You must specify the port using either hostname:port OR --
> smtp-server-port but not both!"
> -}
> -
> -# setup smtp_server var if it was passed in as host:port format
> -if ( $smtp_server =~ /:\d+/) {
> - # if they do pass a host:port form then split it and use the parts
> - @smtp_host_parts = split(/:/, $smtp_server);
> - $smtp_server = $smtp_host_parts[0];
> - $smtp_server_port = $smtp_host_parts[1];
> -}
> -
> -# setup reasonable defaults if neither host:port or --smtp-server-
> port were passed
> -if ( !defined $smtp_server_port) {
> - if ($smtp_ssl) {
> - $smtp_server_port = 465 # SSL port
> - } else {
> - $smtp_server_port = 25 # Non-SSL port
> - }
> -}
> -
> -
> if ($compose) {
> # Note that this does not need to be secure, but we will make a
> small
> # effort to have it be unique
> @@ -632,39 +609,34 @@ X-Mailer: git-send-email $gitversion
> } else {
>
> if (!defined $smtp_server) {
> - die "The required SMTP server is not properly defined."
> - }
> -
> - if (!defined $smtp_server_port || !$smtp_server_port =~ /^\d+$/ ) {
> - die "The required SMTP server port is not properly defined."
> + die "The required SMTP server is not properly defined."
> }
>
> if ($smtp_ssl) {
> + $smtp_server_port ||= 465; # ssmtp
> require Net::SMTP::SSL;
> - $smtp ||= Net::SMTP::SSL->new( $smtp_server, Port =>
> $smtp_server_port );
> + $smtp ||= Net::SMTP::SSL->new($smtp_server, Port =>
> $smtp_server_port);
> }
> else {
> require Net::SMTP;
> - $smtp ||= Net::SMTP->new($smtp_server . ":" . $smtp_server_port);
> + $smtp ||= Net::SMTP->new((defined $smtp_server_port)
> + ? "$smtp_server:$smtp_server_port"
> + : $smtp_server);
> }
>
> - # we'll get an ugly error if $smtp was undefined above.
> - # If so we'll catch it and present something friendlier.
> - if (!$smtp) {
> - die "Unable to initialize SMTP properly. Is there something
> wrong with your config?";
> - }
> -
> - if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
> - $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp-
> >message;
> - }
> -
> - $smtp->mail( $raw_from ) or die $smtp->message;
> - $smtp->to( @recipients ) or die $smtp->message;
> - $smtp->data or die $smtp->message;
> - $smtp->datasend("$header\n$message") or die $smtp->message;
> - $smtp->dataend() or die $smtp->message;
> - $smtp->ok or die "Failed to send $subject\n".$smtp->message;
> + if (!$smtp) {
> + die "Unable to initialize SMTP properly. Is there something
> wrong with your config?";
> + }
>
> + if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
> + $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp-
> >message;
> + }
> + $smtp->mail( $raw_from ) or die $smtp->message;
> + $smtp->to( @recipients ) or die $smtp->message;
> + $smtp->data or die $smtp->message;
> + $smtp->datasend("$header\n$message") or die $smtp->message;
> + $smtp->dataend() or die $smtp->message;
> + $smtp->ok or die "Failed to send $subject\n".$smtp->message;
> }
> if ($quiet) {
> printf (($dry_run ? "Dry-" : "")."Sent %s\n", $subject);
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> index d32907d..83f9470 100755
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -41,16 +41,4 @@ test_expect_success \
> 'Verify commandline' \
> 'diff commandline expected'
>
> -test_expect_failure 'Passing in both host:port form AND --smtp-
> server-port' '
> - git send-email --from="Example <nobody@example.com>" --
> to=nobody@example.com --smtp-server smtp.foo.com:66 --smtp-server-
> port 77" $patches 2>errors
> -'
> -
> -test_expect_failure 'Passing in non-numeric server port with
> host:port form' '
> - git send-email --from="Example <nobody@example.com>" --
> to=nobody@example.com --smtp-server smtp.foo.com:bar" $patches
> 2>errors
> -'
> -
> -test_expect_failure 'Passing in non-numeric server port with --
> smtp-server-port form' '
> - git send-email --from="Example <nobody@example.com>" --
> to=nobody@example.com --smtp-server smtp.foo.com --smtp-server-port
> bar" $patches 2>errors
> -'
> -
> test_done
--
Glenn Rempe
glenn.@rempe.us
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2411 bytes --]
^ permalink raw reply
* Re: Workflow question
From: Jeff King @ 2007-09-26 0:47 UTC (permalink / raw)
To: Russ Brown; +Cc: git
In-Reply-To: <46F97618.9010207@gmail.com>
On Tue, Sep 25, 2007 at 03:56:56PM -0500, Russ Brown wrote:
> I keep reading things similar to this and bit by bit I'm starting to get
> it. :) I suppose this is one case in which it's definitely a
> disadvantage to have a good understanding of svn before coming to git...
>
> <yoda>You must unlearn what you have learned</yoda>
I prefer to think of it like a war movie, where I keep having
nightmarish flashbacks to CVS.
But yes, from the outside git _looks_ a lot like other SCMs you may have
used, and so it's tempting to keep their mental models. But that can
easily end up being confusing, as you have found. Personally, I think it
pays to learn a little about what's going on under the hood, and then
all of the commands Just Make Sense.
There are several explanations floating around; this is a pretty concise
one:
http://eagain.net/articles/git-for-computer-scientists/
> If you delete a branch that has commits on it that aren't referenced by
> any other branches, will those commits be removed by something like git
> pack or git gc?
The 'git-prune' command will do this, though it is not run as part of
git-gc unless you specify --prune.
> I suppose what has me the most confused is how a developer works with a
> remote branch: I've come to understand that a developer should never
> check out and work on a remote branch, and always create a local one and
> work on that. If he does that using the above hierarchy, there then
> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is
> is possible for a developer to work directory on a remote branch?
As Junio noted, you can't, because they're remote. What you have in your
local repository is a remote _tracking branch_, which is a local ref
that tracks your idea of what the remote's branches are. And git will
feel free to overwrite the contents of that tracking branch whenever you
do a fetch or pull. So if you make commits on it, they are subject to
being overwritten (and we note this property of the refs by putting them
in the refs/remotes hierarchy, rather than refs/heads).
So in the case of our developer Jeff, his local repository will have a
"projectX/featureY" branch that he works on. And he will also have a
remote tracking branch "origin/projectX/featureY" which indicates where
his local repo thinks the remote repo points. And the remote repo will
have a "projectX/featureY" branch, of course.
> Ah,I see... The light is beginning to come on somewhat here, though it's
> dimmed somewhat by the remote/local branch confusion I mention above,
> which tends to imply that rebase is only really useful in local branches
> since it is always the outer-most branch (assuming that my understanding
> on that is correct, which it may well not be).
Yes, although the important distinction is not so much "this is a local
branch" but rather "this is a _published_ branch" which implies that
other people are looking at (and possibly basing work on) it.
> I actually quite like the idea of the freezing before re-basing in the
> sub-branches. However, to answer the question of which merge strategy
> would work best for us I think I need to actually set this up and have a
> play with it to see how it all pans out using the various options available.
Yes, it is easy to get into academic discussions of setups, but in
practice you need to find a workflow that is smooth for your team.
On one web-based project I work on, we have a setup like this (which is
very centralized):
- a central repo resides on a development server with two branches,
"master" and "production"
- each developer clones the repo with a working tree
- some developers develop directly on 'master' if they have small
changes, or only work on one thing at a time; other developers use
topic branches to work on simultaneous changes
- any developer can push to master; it is expected that your code is
in a reasonable state, since it will now be consumed by other
developers. Anything that has made it into master is considered
published and should not be rebased. It is up to developers whether
they want to rebase their work before publishing or to simply merge.
- some developers communicate directly with each other: "hey, check
out branch 'foo' in my repo" or "what do you think of this patch?"
- The live site has a repo cloned from the central repo, pointing at
"production".
- there is a test site with a repo cloned from the master.
Occasionally the master branch is pulled and tested. If it passes,
it is pushed to the "production" branch. In addition, small
immediate fixes can go onto "production", tested, and then pushed to
the central repo's "production"
So this is not necessarily using the distributed nature of that much,
but it allows those developers who aren't very comfortable with SCMs to
stick to a "pull, hack, push" workflow. And those who want to can do
more interesting things if it helps them.
-Peff
^ permalink raw reply
* Re: [PATCH] Don't use "<unknown>" for unknown values of placeholders and suppress printing of empty user formats.
From: Junio C Hamano @ 2007-09-26 0:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michal Vitecek, git
In-Reply-To: <Pine.LNX.4.64.0709251543561.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This may have warranted a description in the commit message a la
>
> Instead of setting unknown entries to "<unknown>" in the
> interp_table, we teach interpolate() to replace entries with
> NULL values by the empty string.
Indeed.
> Here are still spaces instead of tabs.
>
> These are only minor details; I don't know if Junio wants to fix them
> himself.
Good eyes.
Also a sign-off is missing ;-)
^ permalink raw reply
* Re: [PATCH 2/2] Make builtin-rerere use of strbuf nicer and more efficient.
From: Junio C Hamano @ 2007-09-26 0:31 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1190625904-22808-3-git-send-email-madcoder@debian.org>
Signoffs?
^ permalink raw reply
* Re: [PATCH] Add ability to specify SMTP server port when using git-send-email.
From: Junio C Hamano @ 2007-09-26 0:27 UTC (permalink / raw)
To: Glenn Rempe; +Cc: git
In-Reply-To: <1190759927-19493-1-git-send-email-glenn@rempe.us>
I'm inclined to do this on top of yours.
* As you mentioned, ssmtp plus undocumented "server:port"
syntax never worked. There is no point supporting the
combination. Also I do not think it is worth additional
lines of code to even say "server:port" plus --server-port
option are not meant to be used together.
* People who used the undocumented "server:port" syntax did not
use the new --smtp-server-port option anyway.
* If somebody goes over plain smtp specifies server without
port, we can let the Net::SMTP to handle the default port.
No need for _us_ to say that the default is 25.
* I do not see much point insisting that port to be numeric; I
do not know what Net::SMTP accepts, but if it accepts
my.isp.com:smtp instead of my.isp.com:25, that is fine. This
has the side effect of keeping people's existing set-up
working.
* The indentation was horrible. Maybe your tabstop is set
incorrectly?
* As I am inclined not to insist on numeric port numbers,
the additional tests become pointless.
The result is much simpler, and I think it is more readable.
---
git-send-email.perl | 64 +++++++++++++-----------------------------------
t/t9001-send-email.sh | 12 ---------
2 files changed, 18 insertions(+), 58 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 886f78f..62e1429 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -380,29 +380,6 @@ if (!defined $smtp_server) {
$smtp_server ||= 'localhost'; # could be 127.0.0.1, too... *shrug*
}
-# don't allow BOTH forms of port definition to work since we can't guess which one is right.
-if (($smtp_server =~ /:\d+/) && (defined $smtp_server_port)) {
- die "You must specify the port using either hostname:port OR --smtp-server-port but not both!"
-}
-
-# setup smtp_server var if it was passed in as host:port format
-if ( $smtp_server =~ /:\d+/) {
- # if they do pass a host:port form then split it and use the parts
- @smtp_host_parts = split(/:/, $smtp_server);
- $smtp_server = $smtp_host_parts[0];
- $smtp_server_port = $smtp_host_parts[1];
-}
-
-# setup reasonable defaults if neither host:port or --smtp-server-port were passed
-if ( !defined $smtp_server_port) {
- if ($smtp_ssl) {
- $smtp_server_port = 465 # SSL port
- } else {
- $smtp_server_port = 25 # Non-SSL port
- }
-}
-
-
if ($compose) {
# Note that this does not need to be secure, but we will make a small
# effort to have it be unique
@@ -632,39 +609,34 @@ X-Mailer: git-send-email $gitversion
} else {
if (!defined $smtp_server) {
- die "The required SMTP server is not properly defined."
- }
-
- if (!defined $smtp_server_port || !$smtp_server_port =~ /^\d+$/ ) {
- die "The required SMTP server port is not properly defined."
+ die "The required SMTP server is not properly defined."
}
if ($smtp_ssl) {
+ $smtp_server_port ||= 465; # ssmtp
require Net::SMTP::SSL;
- $smtp ||= Net::SMTP::SSL->new( $smtp_server, Port => $smtp_server_port );
+ $smtp ||= Net::SMTP::SSL->new($smtp_server, Port => $smtp_server_port);
}
else {
require Net::SMTP;
- $smtp ||= Net::SMTP->new($smtp_server . ":" . $smtp_server_port);
+ $smtp ||= Net::SMTP->new((defined $smtp_server_port)
+ ? "$smtp_server:$smtp_server_port"
+ : $smtp_server);
}
- # we'll get an ugly error if $smtp was undefined above.
- # If so we'll catch it and present something friendlier.
- if (!$smtp) {
- die "Unable to initialize SMTP properly. Is there something wrong with your config?";
- }
-
- if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
- $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
- }
-
- $smtp->mail( $raw_from ) or die $smtp->message;
- $smtp->to( @recipients ) or die $smtp->message;
- $smtp->data or die $smtp->message;
- $smtp->datasend("$header\n$message") or die $smtp->message;
- $smtp->dataend() or die $smtp->message;
- $smtp->ok or die "Failed to send $subject\n".$smtp->message;
+ if (!$smtp) {
+ die "Unable to initialize SMTP properly. Is there something wrong with your config?";
+ }
+ if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
+ $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
+ }
+ $smtp->mail( $raw_from ) or die $smtp->message;
+ $smtp->to( @recipients ) or die $smtp->message;
+ $smtp->data or die $smtp->message;
+ $smtp->datasend("$header\n$message") or die $smtp->message;
+ $smtp->dataend() or die $smtp->message;
+ $smtp->ok or die "Failed to send $subject\n".$smtp->message;
}
if ($quiet) {
printf (($dry_run ? "Dry-" : "")."Sent %s\n", $subject);
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index d32907d..83f9470 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -41,16 +41,4 @@ test_expect_success \
'Verify commandline' \
'diff commandline expected'
-test_expect_failure 'Passing in both host:port form AND --smtp-server-port' '
- git send-email --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server smtp.foo.com:66 --smtp-server-port 77" $patches 2>errors
-'
-
-test_expect_failure 'Passing in non-numeric server port with host:port form' '
- git send-email --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server smtp.foo.com:bar" $patches 2>errors
-'
-
-test_expect_failure 'Passing in non-numeric server port with --smtp-server-port form' '
- git send-email --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server smtp.foo.com --smtp-server-port bar" $patches 2>errors
-'
-
test_done
^ permalink raw reply related
* Re: [PATCH] Add ability to specify SMTP server port when using git-send-email.
From: Glenn Rempe @ 2007-09-26 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Glenn Rempe, git
In-Reply-To: <7vmyva2uqd.fsf@gitster.siamese.dyndns.org>
On Sep 25, 2007, at 4:25 PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> On Tue, 25 Sep 2007, Glenn Rempe wrote:
>>>
>>>> +if (($smtp_server =~ /:\d+/) && (defined $smtp_server_port)) {
>>>
>>> Not that I want to be a PITA, but this breaks down with IPv6, right?
>>
>> Right. Do we care about symbolic "server.addre.ss:smtp"
>> notation as well, I wonder?
>
> Well, does it break?
>
> BTW, I do not think we care about ":smtp"; it was a
> tongue-in-cheek comment.
Unfortunately, I know little about IPv6 and whether this breaks IPv6
addressing or not. So I'll leave that question for others. Does the
unpatched code work with IPv6? Does anyone currently use it that way?
Junio, are you suggesting that I should remove the host:port form
support entirely and leave only the --smtp-server port option as
valid? I kind of liked that this new method allows both forms of
specifying port as equal citizens. :-) If you are suggesting that
it be removed, I think we would have to reject the host:port form
smtp-server addresses so we don't break when both --smtp-
server=host:port and -smtp-ssl are provided. (which brings us back to
the ipv6 question). No?
^ permalink raw reply
* Re: Workflow question
From: Russ Brown @ 2007-09-26 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabra5tah.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Russ Brown <pickscrape@gmail.com> writes:
>
>> I keep reading things similar to this and bit by bit I'm starting to get
>> it. :) I suppose this is one case in which it's definitely a
>> disadvantage to have a good understanding of svn before coming to git...
>>
>> <yoda>You must unlearn what you have learned</yoda>
>
> You do not have to unlearn; if Jeff truly unlearned he wouldn't
> have spotted you were trapped in SVN mentality. You just need
> to learn there could be other ways ;-).
>
I suppose what I really mean is you need to stop assuming what you've
already learned. :)
>> If you delete a branch that has commits on it that aren't referenced by
>> any other branches, will those commits be removed by something like git
>> pack or git gc?
>
> Yes, eventually.
>
>> I suppose what has me the most confused is how a developer works with a
>> remote branch: I've come to understand that a developer should never
>> check out and work on a remote branch, and always create a local one and
>> work on that. If he does that using the above hierarchy, there then
>> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is
>> is possible for a developer to work directory on a remote branch?
>
> The statement in the last sentence does not make any sense.
> Remote is called remote because it is remote and supposed to be
> out of reach ;-)
>
Ah. I think I was a little confused by the fact that git does let you
checkout remote branches, through I see that it does warn you about it
when you do it.
> More seriously, remotes are used as reference points so if you
> "work directly on them", you cannot use them as reference points
> any more; you defeat the sole purpose of existence of remotes.
>
> You can work _without_ using remote tracking branches, but that
> is mostly for merge based workflow. It appears that you are
> leaning towards rebase-heavy workflow, so I do not think it is
> applicable to your project.
Right, I think we're going to be aiming for that, though as I say I'm
going to be experimenting a bit to see how things work when using both
approaches.
Thanks.
--
Russ
^ permalink raw reply
* Re: Unable to connect to the server
From: Johannes Schindelin @ 2007-09-25 23:51 UTC (permalink / raw)
To: Kaushalya Satharasinghe; +Cc: git
In-Reply-To: <1190365837.5497.4.camel@localhost>
Hi,
On Fri, 21 Sep 2007, Kaushalya Satharasinghe wrote:
> I want to checkout a git package. I installed git and when I give the
> command
> "/root/bin/git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git /home/Kaushalya/moreWork/git_test
> "
> I got the result as
>
> Initialized empty Git repository
> in /home/Kaushalya/moreWork/git_test/.git/
> git.kernel.org[0: 140.211.167.38]: errno=Connection timed out
> fatal: unable to connect a socket (Connection timed out)
> fetch-pack from
> 'git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git' failed.
>
> I can ping the 140.211.167.38. I am using Fedora Core 5 hosted through
> vmware 5.5. Can anyone help me out here?
You're probably quite a few hops away from that machine. However, mmc.git
is a fork of the kernel tree, so if you can get ahold of any other kernel
repository (for example from repo.or.cz), you can easen the load by using
the --reference option to git-clone.
Hth,
Dscho
^ permalink raw reply
* Unable to connect to the server
From: Kaushalya Satharasinghe @ 2007-09-21 9:10 UTC (permalink / raw)
To: git
Hi,
I want to checkout a git package. I installed git and when I give the
command
"/root/bin/git clone
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git /home/Kaushalya/moreWork/git_test
"
I got the result as
Initialized empty Git repository
in /home/Kaushalya/moreWork/git_test/.git/
git.kernel.org[0: 140.211.167.38]: errno=Connection timed out
fatal: unable to connect a socket (Connection timed out)
fetch-pack from
'git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git' failed.
I can ping the 140.211.167.38. I am using Fedora Core 5 hosted through
vmware 5.5. Can anyone help me out here?
Thanks and regards,
--
Kaushalya Satharasinghe <kaushalyas@zone24x7.com>
Zone24x7
^ permalink raw reply
* Re: [PATCH] Add ability to specify SMTP server port when using git-send-email.
From: Junio C Hamano @ 2007-09-25 23:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Glenn Rempe, git
In-Reply-To: <7vzlza2vcl.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Tue, 25 Sep 2007, Glenn Rempe wrote:
>>
>>> +if (($smtp_server =~ /:\d+/) && (defined $smtp_server_port)) {
>>
>> Not that I want to be a PITA, but this breaks down with IPv6, right?
>
> Right. Do we care about symbolic "server.addre.ss:smtp"
> notation as well, I wonder?
Well, does it break?
BTW, I do not think we care about ":smtp"; it was a
tongue-in-cheek comment.
^ permalink raw reply
* Re: [PATCH] post-merge hook and related tests
From: Junio C Hamano @ 2007-09-25 23:21 UTC (permalink / raw)
To: Josh England; +Cc: git
In-Reply-To: <1190760563-32453-2-git-send-email-jjengla@sandia.gov>
"Josh England" <jjengla@sandia.gov> writes:
> Signed-off-by: Josh England <jjengla@sandia.gov>
> ---
> git-merge.sh | 13 ++++++++++
> t/t5402-post-merge-hook.sh | 56 ++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 69 insertions(+), 0 deletions(-)
> create mode 100644 t/t5402-post-merge-hook.sh
I think this is part of the 'master' for at least a few days, so
is a half of the Documentation patch.
^ permalink raw reply
* Re: [PATCH] post-checkout hooks and related tests
From: Junio C Hamano @ 2007-09-25 23:17 UTC (permalink / raw)
To: Josh England; +Cc: git
In-Reply-To: <1190760563-32453-1-git-send-email-jjengla@sandia.gov>
"Josh England" <jjengla@sandia.gov> writes:
> diff --git a/git-checkout.sh b/git-checkout.sh
> index 17f4392..78355eb 100755
> --- a/git-checkout.sh
> +++ b/git-checkout.sh
> @@ -137,6 +137,13 @@ Did you intend to checkout '$@' which can not be resolved as commit?"
> git ls-files --error-unmatch -- "$@" >/dev/null || exit
> git ls-files -- "$@" |
> git checkout-index -f -u --stdin
> +
> + # Run a post-checkout hook -- the HEAD does not change so the
> + # current HEAD is passed in for both args
> + if test -x "$GIT_DIR"/hooks/post-checkout; then
It is usually a good idea to view your patch in your MUA before
sending them out.
You will spot HT vs SP indentation inconsistencies right away.
HEAD did not change but don't you want to differenciate if the
checkout was from the index or from the HEAD? If not why not?
^ permalink raw reply
* Re: [PATCH] Add ability to specify SMTP server port when using git-send-email.
From: Junio C Hamano @ 2007-09-25 23:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Glenn Rempe, git
In-Reply-To: <Pine.LNX.4.64.0709260004090.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 25 Sep 2007, Glenn Rempe wrote:
>
>> +if (($smtp_server =~ /:\d+/) && (defined $smtp_server_port)) {
>
> Not that I want to be a PITA, but this breaks down with IPv6, right?
Right. Do we care about symbolic "server.addre.ss:smtp"
notation as well, I wonder?
^ 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