From: Junio C Hamano <hidden> Date: 2016-06-15 22:46:03
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* jc/maint-1.6.0-split-diff-metainfo (Mon Jan 26 00:08:24 2009 -0800) 1 commit
+ diff.c: output correct index lines for a split diff
This is slated for maintenance series 1.6.0.X, 1.6.1.X and also for
'master'. I think the change is pretty safe and sane to go directly to
'master' but I had too many other topoics to look at that I did not feel
comfortable enough to do so.
* jc/maint-split-diff-metainfo (Tue Jan 27 01:08:02 2009 -0800) 2 commits
+ Merge branch 'jc/maint-1.6.0-split-diff-metainfo' into jc/maint-
split-diff-metainfo
+ diff.c: output correct index lines for a split diff
Early conflict resolution branch for the above to carry it to 1.6.1X
series.
* js/maint-rebase-i-submodule (Tue Jan 27 12:42:31 2009 +0100) 2 commits
+ Fix submodule squashing into unrelated commit
+ rebase -i squashes submodule changes into unrelated commit
* jg/tag-contains (Mon Jan 26 09:13:25 2009 -0500) 3 commits
+ git-tag: Add --contains option
+ Make has_commit() non-static
+ Make opt_parse_with_commit() non-static
* jk/maint-cleanup-after-exec-failure (Wed Jan 28 02:38:14 2009 -0500) 4 commits
+ git: use run_command() to execute dashed externals
+ run_command(): help callers distinguish errors
+ run_command(): handle missing command errors more gracefully
+ git: s/run_command/run_builtin/
* jc/maint-allow-uninteresting-missing (Tue Jan 27 23:19:30 2009 -0800) 1 commit
+ revision traversal: allow UNINTERESTING objects to be missing
This is a small follow-up to the fix to send-pack in 1.6.1; meant to go in
1.6.1.X maintenance series and newer.
* am/maint-push-doc (Mon Jan 26 00:45:33 2009 +0100) 3 commits
+ Documentation: rework src/dst description in git push
+ Documentation: more git push examples
+ Documentation: simplify refspec format description
* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
- git-merge-file: allow converting the results for the work tree
We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path". Instead, merge-file simply wrote out the
data in the canonical repository representation.
rerere has the same issue, but it is a lot worse. It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out. It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree(). It also needs to write
in binary mode as well.
* jc/maint-add-u-remove-conflicted (Wed Jan 28 14:24:53 2009 -0800) 1 commit
- add -u: do not fail to resolve a path as deleted
This has been updated from the posted version with a correction.
* ns/am-slacker (Sat Jan 24 10:18:02 2009 +0900) 2 commits
+ git-am: Add --ignore-date option
+ am: Add --committer-date-is-author-date option
It is a (probably) useful new feature with a sort-of cute explanation.
* jc/maint-apply-fix (Sun Jan 25 23:41:26 2009 -0800) 1 commit
+ builtin-apply.c: do not set bogus mode in check_preimage() for
deleted path
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
The "spec" did not seem quite well cooked yet, but in the longer term I
think something like this to allow interoperating with other SCMs as if
the other end is a native git repository is a very worthy goal.
* cc/replace (Fri Jan 23 10:07:46 2009 +0100) 7 commits
- environment: add global variable to disable replacement
- mktag: call "check_sha1_signature" with the replacement sha1
- replace_object: add a test case
- object: call "check_sha1_signature" with the replacement sha1
- sha1_file: add a "read_sha1_file_repl" function
- replace_object: add mechanism to replace objects found in
"refs/replace/"
- refs: add a "for_each_replace_ref" function
Nobody has review comments on this yet.
* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 6 commits
- archive.c: add support for --submodules[=(all|checkedout)]
- tree.c: allow read_tree_recursive() to traverse gitlink entries
+ Revert round #1 of the series
+ builtin-ls-tree: enable traversal of submodules
+ archive.c: enable traversal of submodules
+ tree.c: add support for traversal of submodules
----------------------------------------------------------------
[Reverted]
* mh/unify-color (Fri Jan 23 01:25:23 2009 -0800) 3 commits
? Revert previous two commits
? move the color variables to color.c
? handle color.ui at a central place
This broke git-format-patch badly.
----------------------------------------------------------------
[Actively cooking]
* js/valgrind (Wed Jan 21 02:36:40 2009 +0100) 2 commits
- valgrind: ignore ldso errors
- Add valgrind support in test scripts
Dscho and Peff had further exchanges on the list; I am sort of waiting for
the conclusion before picking any intermediate version up.
* ks/maint-mailinfo-folded (Tue Jan 13 01:21:04 2009 +0300) 4 commits
+ mailinfo: tests for RFC2047 examples
+ mailinfo: add explicit test for mails like '[off-list ref]
(A U Thor)'
+ mailinfo: 'From:' header should be unfold as well
+ mailinfo: correctly handle multiline 'Subject:' header
I just got tired of waiting and cleaned up the series myself.
* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
+ git-notes: fix printing of multi-line notes
+ notes: fix core.notesRef documentation
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
It would be nice to hear a real world success story using the notes
mechanism; Dscho says he also wants to make sure the current choice
of the structure scales well before casting it in stone.
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
Design discussion between Jakub and Sebastien continues.
----------------------------------------------------------------
[Graduated to "master"]
* sr/clone-empty (Fri Jan 23 01:07:32 2009 +0100) 1 commit
+ Allow cloning an empty repository
Has anybody actually tried this and made sure the resulting empty clone
works fine after the clone source gets updated with some contents?
* kb/lstat-cache (Sun Jan 18 16:14:54 2009 +0100) 5 commits
+ lstat_cache(): introduce clear_lstat_cache() function
+ lstat_cache(): introduce invalidate_lstat_cache() function
+ lstat_cache(): introduce has_dirs_only_path() function
+ lstat_cache(): introduce has_symlink_or_noent_leading_path()
function
+ lstat_cache(): more cache effective symlink/directory detection
* tr/previous-branch (Wed Jan 21 00:37:38 2009 -0800) 10 commits
+ Simplify parsing branch switching events in reflog
+ Introduce for_each_recent_reflog_ent().
+ interpret_nth_last_branch(): plug small memleak
+ Fix reflog parsing for a malformed branch switching entry
+ Fix parsing of @{-1}@{1}
+ interpret_nth_last_branch(): avoid traversing the reflog twice
+ checkout: implement "-" abbreviation, add docs and tests
+ sha1_name: support @{-N} syntax in get_sha1()
+ sha1_name: tweak @{-N} lookup
+ checkout: implement "@{-N}" shortcut name for N-th last branch
* js/maint-all-implies-HEAD (Sat Jan 17 22:27:08 2009 -0800) 2 commits
+ bundle: allow the same ref to be given more than once
+ revision walker: include a detached HEAD in --all
* cb/add-pathspec (Wed Jan 14 15:54:35 2009 +0100) 2 commits
+ remove pathspec_match, use match_pathspec instead
+ clean up pathspec matching
* js/diff-color-words (Tue Jan 20 22:59:54 2009 -0600) 9 commits
+ Change the spelling of "wordregex".
+ color-words: Support diff.wordregex config option
+ color-words: make regex configurable via attributes
+ color-words: expand docs with precise semantics
+ color-words: enable REG_NEWLINE to help user
+ color-words: take an optional regular expression describing words
+ color-words: change algorithm to allow for 0-character word
boundaries
+ color-words: refactor word splitting and use ALLOC_GROW()
+ Add color_fwrite_lines(), a function coloring each line
individually
----------------------------------------------------------------
[Will merge to "master" soon]
* jg/mergetool (Sat Jan 24 00:12:45 2009 +0100) 1 commit
+ mergetool: Don't repeat merge tool candidates
* cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit
+ mergetool: respect autocrlf by using checkout-index
Now Ted told us not to wait for him, we'll go ahead by ourselves ;-).
* jk/signal-cleanup (Thu Jan 22 01:03:28 2009 -0500) 5 commits
+ pager: do wait_for_pager on signal death
+ refactor signal handling for cleanup functions
+ chain kill signals for cleanup functions
+ diff: refactor tempfile cleanup handling
+ Windows: Fix signal numbers
* sp/runtime-prefix (Sun Jan 18 13:00:15 2009 +0100) 7 commits
+ Windows: Revert to default paths and convert them by
RUNTIME_PREFIX
+ Compute prefix at runtime if RUNTIME_PREFIX is set
+ Modify setup_path() to only add git_exec_path() to PATH
+ Add calls to git_extract_argv0_path() in programs that call
git_config_*
+ git_extract_argv0_path(): Move check for valid argv0 from caller
to callee
+ Refactor git_set_argv0_path() to git_extract_argv0_path()
+ Move computation of absolute paths from Makefile to runtime (in
preparation for RUNTIME_PREFIX)
----------------------------------------------------------------
[On Hold]
* jc/commit-assume-also-during-merge (Thu Jan 22 22:21:49 2009 -0800) 3 commits
- git commit: pathspec without -i/-o implies -i semantics during a
merge
- builtin-commit: shorten eye-sore overlong lines
- Add "partial commit" tests during a conflicted merge
This is only meant as a weatherballoon to help facilitate discussion.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
. revision --simplify-merges: incremental simplification
. revision --simplify-merges: prepare for incremental simplification
* jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits
. valgrind: ignore ldso errors
. add valgrind support in test scripts
* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
. In add --patch, Handle K,k,J,j slightly more gracefully.
. Add / command in add --patch
. git-add -i/-p: Change prompt separater from slash to comma
From: Jeff King <hidden> Date: 2016-06-15 22:46:03
On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
* js/valgrind (Wed Jan 21 02:36:40 2009 +0100) 2 commits
- valgrind: ignore ldso errors
- Add valgrind support in test scripts
Dscho and Peff had further exchanges on the list; I am sort of waiting for
the conclusion before picking any intermediate version up.
I think I gave an OK to the last version posted, but then the last thing
I saw from Dscho was "I have a new patch, but I'm not posting it right
this second":
http://article.gmane.org/gmane.comp.version-control.git/107300
followed by much "is zlib broken" discussion which I think doesn't hold
us up (either it is a bug in zlib, in which case it is not our problem,
or it is a false positive, in which case we just add a suppression).
So I think we are waiting for the next round from Johannes.
* jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits
. valgrind: ignore ldso errors
. add valgrind support in test scripts
I think it probably makes sense to drop these at this point. Dscho's
more recent work should be the basis to which new patches are compared.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:46:03
On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
* sr/clone-empty (Fri Jan 23 01:07:32 2009 +0100) 1 commit
+ Allow cloning an empty repository
Has anybody actually tried this and made sure the resulting empty clone
works fine after the clone source gets updated with some contents?
Hmm. It sort of works:
$ mkdir parent && (cd parent && git init)
Initialized empty Git repository in /home/peff/parent/.git/
$ git clone parent child
Initialized empty Git repository in /home/peff/child/.git/
warning: You appear to have cloned an empty repository.
So far so good...
$ (cd parent && echo content >file && git add file && git commit -m one)
[normal commit output]
$ (cd child && git fetch)
[normal fetch output]
But:
$ (cd child && git pull)
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
...
So it's not quite seamless. The problem is that we're not setting up the
branch.master.* config on the empty clone. Nor do we set up
refs/remotes/origin/HEAD.
On top of that, I get funniness between versions:
$ ssh peff.net 'git version && mkdir foo && cd foo && git init'
git version 1.5.6.5
Initialized empty Git repository in /mnt/data/home/peff/foo/.git/
$ git clone peff.net:foo
Initialized empty Git repository in /home/peff/foo/.git/
warning: You appear to have cloned an empty repository.
$ fatal: The remote end hung up unexpectedly
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:46:03
On Wed, Jan 28, 2009 at 10:51:38PM -0500, Jeff King wrote:
But:
$ (cd child && git pull)
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
...
So it's not quite seamless. The problem is that we're not setting up the
branch.master.* config on the empty clone. Nor do we set up
refs/remotes/origin/HEAD.
Hrm. I was thinking we checked out "master" as a branch yet to be born,
but of course that doesn't work because we don't even know that the name
"master" exists on the other side (to do that, we would need an
extension to transmit symref information for a ref yet to be born).
We could always assume the remote side is going to eventually put
content on "master" (we know they aren't using another branch _now_, or
the repo wouldn't be empty, so we are just guessing they will follow the
usual convention). That feels a bit hack-ish, though.
So the current behavior is probably sane. But it is not obvious to a
user how to extend their repo one the upstream isn't empty. Maybe the
"empty repo" warning could mention "git fetch && git checkout -b master
origin/master" (which is the most obvious way I can think of)?
-Peff
From: Charles Bailey <hidden> Date: 2016-06-15 22:46:03
On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
* cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit
+ mergetool: respect autocrlf by using checkout-index
Can you hold off on merging this one? I now think that there's a
cleaner way of doing this and I would like the opportunity for a
rethink.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
On Thu, Jan 29, 2009 at 04:51, Jeff King [off-list ref] wrote:
$ mkdir parent && (cd parent && git init)
Initialized empty Git repository in /home/peff/parent/.git/
$ git clone parent child
Initialized empty Git repository in /home/peff/child/.git/
warning: You appear to have cloned an empty repository.
So far so good...
$ (cd parent && echo content >file && git add file && git commit -m one)
[normal commit output]
$ (cd child && git fetch)
[normal fetch output]
I thought instead we wanted to support the following workflow:
$ (cd child && echo content >file && git add file && git commit -m one)
[normal commit output]
Which is what the testcase tests. E.g., we want to support cloning an
empty repo so that the user can then _push_ to that repository to make
it non-empty, no?
--
Cheers,
Sverre Rabbelier
From: Jeff King <hidden> Date: 2016-06-15 22:46:03
On Thu, Jan 29, 2009 at 12:27:23PM +0100, Sverre Rabbelier wrote:
I thought instead we wanted to support the following workflow:
$ (cd child && echo content >file && git add file && git commit -m one)
[normal commit output]
Which is what the testcase tests. E.g., we want to support cloning an
empty repo so that the user can then _push_ to that repository to make
it non-empty, no?
True, that is probably going to be more common (otherwise, why would the
person who is going to push into the empty repo advertise it to you
before they have put any content in it).
But it will probably still be surprising not to have the branch merging
setup:
mkdir parent && (cd parent && git init) &&
git clone parent child && cd child &&
echo content >file && git add file && git commit -m one &&
git push origin master ;# note we have to explicitly mention the branch
... time passes ...
git pull
produces the "you haven't asked me which branch to merge" message.
Which does make some sense, given how tracking configuration is set up.
It's just that it's a little sad that cloning an empty repository and
then later getting commits out of it (whether commits you put in or
somebody else) does not behave the same as cloning a repository with
commits.
Which I thought was sort of the point, that this would work seamlessly.
Otherwise, there is not much advantage over:
mkdir parent && (cd parent && git init) &&
mkdir child && cd child && git init &&
echo content >file && git add file && git commit -m one &&
git push origin master ;# note we have to explicitly mention the branch
With the empty clone, you get your "origin" remote set up, but in both
cases you are missing the branch tracking.
I don't know if there is a good solution, though. Perhaps it's best to
just let what's there get released and see if people complain.
-Peff
From: Pieter de Bie <hidden> Date: 2016-06-15 22:46:03
On 29 jan 2009, at 11:37, Jeff King wrote:
git push origin master ;# note we have to explicitly mention the
branch
... time passes ...
git pull
produces the "you haven't asked me which branch to merge" message.
Which does make some sense, given how tracking configuration is set
up.
It's just that it's a little sad that cloning an empty repository and
then later getting commits out of it (whether commits you put in or
somebody else) does not behave the same as cloning a repository with
commits.
This is true in all cases. If you create a new branch in any repository,
push that, and later do a 'git pull', you get that message. I agree it's
not the nicest way to handle things, but this is not an issue with the
clone,
it's an issue of pushing new branches in general.
On Thu, Jan 29, 2009 at 12:40, Pieter de Bie [off-list ref] wrote:
This is true in all cases. If you create a new branch in any repository,
push that, and later do a 'git pull', you get that message. I agree it's
not the nicest way to handle things, but this is not an issue with the
clone, it's an issue of pushing new branches in general.
Mhhh, so maybe we want a way to set up tracking branches when pushing,
yes? From what I've seen a patch to do that shouldn't be too hard, so
if there's interest in that I could look into that.
--
Cheers,
Sverre Rabbelier
From: Jeff King <hidden> Date: 2016-06-15 22:46:03
On Thu, Jan 29, 2009 at 11:40:42AM +0000, Pieter de Bie wrote:
This is true in all cases. If you create a new branch in any
repository, push that, and later do a 'git pull', you get that
message. I agree it's not the nicest way to handle things, but this is
not an issue with the clone, it's an issue of pushing new branches in
general.
Right. I guess I was hoping by cloning an existing repository, even one
with no commits on the branch, that we could somehow remember that we
are "on" the master branch. I think that is what people who ask for
empty cloning really want:
1. make a bare upstream
2. clone empty repo
3. create commits
4. git push / git pull, as if we had cloned non-empty repo
And I know that it is not very "git" to talk about empty branches, since
branches are pointers into the DAG. But we already do similar trickery
with "yet to be born" branches by putting a dangling symref into HEAD.
But I don't think there's any way currently to send those dangling
symrefs across the git protocol, which is what would be required to do
the above accurately.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:46:03
On Thu, Jan 29, 2009 at 12:45:23PM +0100, Sverre Rabbelier wrote:
On Thu, Jan 29, 2009 at 12:40, Pieter de Bie [off-list ref] wrote:
quoted
This is true in all cases. If you create a new branch in any repository,
push that, and later do a 'git pull', you get that message. I agree it's
not the nicest way to handle things, but this is not an issue with the
clone, it's an issue of pushing new branches in general.
Mhhh, so maybe we want a way to set up tracking branches when pushing,
yes? From what I've seen a patch to do that shouldn't be too hard, so
if there's interest in that I could look into that.
I think that would be reasonable. It wouldn't help the case of "somebody
else pushed some content that you want to pull", but like you said, I
think the primary workflow is that you immediately push after cloning
the empty repo.
-Peff
Jeff King [Thu, Jan 29, 2009 at 06:48:34AM -0500]:
[...] I think that is what people who ask for empty cloning really want:
1. make a bare upstream
2. clone empty repo
3. create commits
4. git push / git pull, as if we had cloned non-empty repo
I must confess, as a user I would like to do
1. create local repo
2. create a remote
3. push it
I don't care about creating empty repos somewhere:
My aim is to publish my work, that's it.
Comments on the steps:
1.1. I don't care whether I push a empty repo or not. But pushing an empty
one does not make much sense, so refusing this would be reasonable
1.2. When creating a new repo, it would be helpful if I can directly add a
description: git init [description] would be nice to have
2.1. I (as a user) understand that I need to create a remote where I have to
push to. It would be helpful to specify --track-this/--merge-this to
have it automatically connected to the current branch
3.1. I would really like to see something like git push
--create[-if-not-exists]. This makes sense for me, but could also
be a global configuration option (push.autocreate = true|false).
Just a comment from a user's point of view ;-)
Sincerly,
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
On Thu, Jan 29, 2009 at 12:50, Jeff King [off-list ref] wrote:
I think that would be reasonable.
Yay :).
It wouldn't help the case of "somebody
else pushed some content that you want to pull", but like you said, I
think the primary workflow is that you immediately push after cloning
the empty repo.
Also, the only way to support the "somebody else pushed already"
workflow would be to assume the user wants to name the branch
'master', which might not be the case at all.
--
Cheers,
Sverre Rabbelier
From: Jeff King <hidden> Date: 2016-06-15 22:46:03
On Thu, Jan 29, 2009 at 01:20:20PM +0100, Sverre Rabbelier wrote:
quoted
It wouldn't help the case of "somebody
else pushed some content that you want to pull", but like you said, I
think the primary workflow is that you immediately push after cloning
the empty repo.
Also, the only way to support the "somebody else pushed already"
workflow would be to assume the user wants to name the branch
'master', which might not be the case at all.
You could make a guess that they will use "master", and if you are
wrong, it behaves as now. But if you are right, "git pull" pulls down
master automatically.
But that is getting a little confusing. So let's push this "git push
--track" idea to completion and see how people like it.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:46:04
On Thu, Jan 29, 2009 at 01:04:55PM +0100, Nico -telmich- Schottelius wrote:
I must confess, as a user I would like to do
1. create local repo
2. create a remote
3. push it
I don't care about creating empty repos somewhere:
My aim is to publish my work, that's it.
I think people have asked for that before, too. The fundamental problem
is that we don't necessarily know how to create the remote repo, or even
have permissions to do so.
If your transport is vanilla ssh, then in theory we could turn
"host:path.git" into "ssh host 'GIT_DIR=path.git git init'". But for
other transports we are out of luck. And for hosting sites like github,
we are out of luck, as you use the web interface to make a new repo.
1.2. When creating a new repo, it would be helpful if I can directly add a
description: git init [description] would be nice to have
I don't think there is any fundamental reason not to allow more setup of
internal .git/* files through 'init'. In most cases, you could just as
easily "echo description >.git/description" afterwards, but it might be
slightly more convenient if you are ssh'ing to do it all in one shot.
2.1. I (as a user) understand that I need to create a remote where I have to
push to. It would be helpful to specify --track-this/--merge-this to
have it automatically connected to the current branch
git remote add -t master origin $URL ?
3.1. I would really like to see something like git push
--create[-if-not-exists]. This makes sense for me, but could also
be a global configuration option (push.autocreate = true|false).
I think this would be better as a feature of "git remote". I.e.:
git remote add --create -t master origin $URL
but again, we can only sanely do creation magic in a subset of cases.
Which is why I think nobody has implemented it so far.
-Peff
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:04
Hi,
On Thu, 29 Jan 2009, Jeff King wrote:
On Thu, Jan 29, 2009 at 01:20:20PM +0100, Sverre Rabbelier wrote:
quoted
quoted
It wouldn't help the case of "somebody
else pushed some content that you want to pull", but like you said, I
think the primary workflow is that you immediately push after cloning
the empty repo.
Also, the only way to support the "somebody else pushed already"
workflow would be to assume the user wants to name the branch
'master', which might not be the case at all.
You could make a guess that they will use "master", and if you are
wrong, it behaves as now. But if you are right, "git pull" pulls down
master automatically.
But that is getting a little confusing. So let's push this "git push
--track" idea to completion and see how people like it.
How about installing
[branch "master"]
remote = origin
merge = refs/heads/master
by default? It is a safe bet that this will be the case for 99% of all
users that want to clone an empty repository (especially if they are
putting their public repositories on something like repo.or.cz, where you
cannot change the default branch from "master" to something else).
And if somebody wants to track another branch, tough, she has to call
this:
$ git checkout -t origin/blablabla
Ciao,
Dscho
From: Jeff King <hidden> Date: 2016-06-15 22:46:04
On Fri, Jan 30, 2009 at 02:18:32PM +0100, Johannes Schindelin wrote:
quoted
You could make a guess that they will use "master", and if you are
wrong, it behaves as now. But if you are right, "git pull" pulls down
master automatically.
But that is getting a little confusing. So let's push this "git push
--track" idea to completion and see how people like it.
How about installing
[branch "master"]
remote = origin
merge = refs/heads/master
by default? It is a safe bet that this will be the case for 99% of all
users that want to clone an empty repository (especially if they are
putting their public repositories on something like repo.or.cz, where you
cannot change the default branch from "master" to something else).
And if somebody wants to track another branch, tough, she has to call
this:
$ git checkout -t origin/blablabla
I was tempted to suggest that, but I haven't thought through whether
there are any lurking corner cases (which empty clone seems to be
fraught with). So I think it is a reasonable thing to try and play with.
-Peff
From: Junio C Hamano <hidden> Date: 2016-06-15 22:46:04
Johannes Schindelin [off-list ref] writes:
How about installing
[branch "master"]
remote = origin
merge = refs/heads/master
by default? It is a safe bet that this will be the case for 99% of all
users that want to clone an empty repository (especially if they are
putting their public repositories on something like repo.or.cz, where you
cannot change the default branch from "master" to something else).
I think this is a reasonable thing to do. Even though cloning from a void
is not entirely a reasonable thing to do to begin with, because we are
going ahead to allow it now, it would be the best thing to do when cloning
a repository served by the currently deployed git.
We _could_ do better if we were to resurrect my earlier series to add
"where does the HEAD point at" protocol extension, but even then we would
need a fallback like your suggestion when talking to older servers anyway.
On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
[...]
* ks/maint-mailinfo-folded (Tue Jan 13 01:21:04 2009 +0300) 4 commits
+ mailinfo: tests for RFC2047 examples
+ mailinfo: add explicit test for mails like '[off-list ref]
(A U Thor)'
+ mailinfo: 'From:' header should be unfold as well
+ mailinfo: correctly handle multiline 'Subject:' header
I just got tired of waiting and cleaned up the series myself.
Sorry about that. Here is the missing bit (based on master)
--- 8< ---
Subject: [PATCH] mailinfo: cleanup extra spaces for complex 'From:'
currently for cases like
From: A U Thor [off-list ref] (Comment)
mailinfo extracts the following 'Author:' field:
Author: A U Thor (Comment)
^^
which has two extra spaces left in there after removed email part.
I think this is wrong so here is a fix.
Signed-off-by: Kirill Smelkov <redacted>
---
builtin-mailinfo.c | 19 +++++++++++++++----
t/t5100/info0001 | 2 +-
t/t5100/rfc2047-info-0004 | 2 +-
t/t5100/sample.mbox | 4 ++--
4 files changed, 19 insertions(+), 8 deletions(-)
@@ -109,11 +112,19 @@ static void handle_from(const struct strbuf *from)strbuf_add(&email,at,el);strbuf_remove(&f,at-f.buf,el+(at[el]?1:0));-/* The remainder is name. It could be "John Doe <john.doe@xz>"-*or"john.doe@xz (John Doe)",butwehaveremovedthe-*emailpart,sotrimfrombothends,possiblyremoving-*the()pairattheend.+/* The remainder is name. It could be+*+*-"John Doe <john.doe@xz>"(a),or+*-"john.doe@xz (John Doe)"(b),or+*-"John (zzz) Doe <john.doe@xz> (Comment)"(c)+*+*butwehaveremovedtheemailpart,so+*+*-removeextraspaceswhichcouldstayafteremail(case'c'),and+*-trimfrombothends,possiblyremovingthe()pairattheend+*(cases'a'and'b').*/+cleanup_space(&f);strbuf_trim(&f);if(f.buf[0]=='('&&f.len&&f.buf[f.len-1]==')'){strbuf_remove(&f,0,1);