Re: [PATCH v5 01/28] path.c: make get_pathname() return strbuf instead of static buffer
On Sat, Mar 8, 2014 at 1:11 PM, Torsten Bögershausen tbo...@web.de wrote: On 2014-03-08 03.47, Nguyễn Thái Ngọc Duy wrote: We've been avoiding PATH_MAX whenever possible. This patch makes get_pathname() return a strbuf and updates the callers to take advantage of this. The code is simplified as we no longer need to worry about buffer overflow. vsnpath() behavior is changed slightly: previously it always clears Minor question: Is the function name vsnpath() appropriate any more ? How about renaming the function into strbuf_vaddpath() ? It is renamed in 04/28 to do_git_path(). -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/11] Add interpret-trailers builtin
Junio C Hamano gitster at pobox.com writes: ... is easier to read and maintain if written like so (with using HT properly---our MUAs may damage it and turn the indentation into spaces): ... sed -e s/ Z$/ / expect -\EOF Fixes: Z Acked-by= Z Reviewed-by: Z Signed-off-by: Z EOF ... How about: printf '%s: \n' Fixes Acked-by Reviewed-by Signed-off-by expect This solution scores high marks in both readability and maintainability in my mind. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git 1.9.0 segfault
Hi, http://pastebin.com/Np7L54ar Cheers, -- Guillaume Gelin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 1.9.0 segfault
On Sat, Mar 08, 2014 at 04:23:43PM +, Guillaume Gelin wrote: Hi, http://pastebin.com/Np7L54ar I can confirm this. I get the following backtrace: Core was generated by `/home/bmc/checkouts/git/git mv packages/ lisp'. Program terminated with signal 11, Segmentation fault. #0 0x7fe31a4371b2 in _IO_vfprintf_internal (s=s@entry=0x7fffa330d2e0, format=optimized out, format@entry=0x7fffa330e5b0 renaming '%s' failed: Bad address, ap=ap@entry=0x7fffa330e498) at vfprintf.c:1649 1649 vfprintf.c: No such file or directory. (gdb) bt #0 0x7fe31a4371b2 in _IO_vfprintf_internal (s=s@entry=0x7fffa330d2e0, format=optimized out, format@entry=0x7fffa330e5b0 renaming '%s' failed: Bad address, ap=ap@entry=0x7fffa330e498) at vfprintf.c:1649 #1 0x7fe31a4e2315 in ___vsnprintf_chk (s=s@entry=0x7fffa330d450 renaming '0\243\377\177, maxlen=optimized out, maxlen@entry=4096, flags=flags@entry=1, slen=slen@entry=4096, format=0x7fffa330e5b0 renaming '%s' failed: Bad address, format@entry=0x544fe5 fatal: , args=0x7fffa330e498) at vsnprintf_chk.c:63 #2 0x005041cb in vsnprintf (__ap=optimized out, __fmt=0x544fe5 fatal: , __n=4096, __s=0x7fffa330d450 renaming '0\243\377\177) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:77 #3 vreportf (prefix=prefix@entry=0x544fe5 fatal: , err=optimized out, params=optimized out) at usage.c:12 #4 0x00504224 in die_builtin (err=optimized out, params=optimized out) at usage.c:36 #5 0x00504650 in die_errno (fmt=0x52be9a renaming '%s' failed) at usage.c:137 #6 0x0044cb4d in cmd_mv (argc=optimized out, argv=optimized out, prefix=optimized out) at builtin/mv.c:246 #7 0x0040602d in run_builtin (argv=0x7fffa330ef90, argc=3, p=0x779d40 commands+1536) at git.c:314 #8 handle_builtin (argc=3, argv=0x7fffa330ef90) at git.c:487 #9 0x004052e1 in run_argv (argv=0x7fffa330ee48, argcp=0x7fffa330ee2c) at git.c:533 #10 main (argc=3, av=optimized out) at git.c:616 We're failing to rename because we got an EFAULT, and then we try to print the failing filename, and we get a segfault right here: if (rename(src, dst) 0 !ignore_errors) die_errno (_(renaming '%s' failed), src); I don't know yet if dst is also bad, but clearly src is. I'm looking into it. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [GSoC14][RFC] Proposal Draft: Refactor tempfile handling
Excellent, thank you very much for the feedback, Jeff! It was very helpful and encouraging. I've done some more research based on your comments. Once the logic is extracted into a nice API, there are several other places that can use it, too: ... I've found the following four areas so far: 1. lockfile.lock_file 2. git-compat-util.odb_mkstemp 3. git-compat-util.odb_pack_keep 4. diff.prepare_temp_file Tons of files use (1) and (2). (3) is less common, and (4) is only used for external diffs. the shallow_XX tempfiles I'm not sure I was able to find this one. Are you referring to the lock files used when fetching, such as in fetch-pack.c? What are the mismatches in how lockfiles and object files are handled? E.g., how do we finalize them into place? How should the API be designed to minimize race conditions (e.g., if we get a signal delivered while we are committing or cleaning up a file)? I'd say the biggest difference between lockfiles and object files is that tempfile methods like odb_mkstemp need to know the location of the object directory. Aside from that, lockfiles and the external diff files appear to be cleaned up at exit, while temporary object files tend to have a more finely controlled lifecycle. I'm still investigating this aspect of the proposal, though. One question, though: the idea on the ideas page specifies that temporary pack and object files may optionally be cleaned up in case of error during program execution. How will users specify their preference? I think the API for creating temporary files should allow cleanup options to be specified on a per-file basis. That way each part of the program that creates tempfiles can specify a different config value to determine the cleanup policy. Thanks for all your help so far! - Brian Gesiak PS: I'm maintaining a working draft of my proposal here, in case anyone wants to offer any feedback prior to its submission: https://gist.github.com/modocache/9434914 On Tue, Mar 4, 2014 at 7:42 AM, Jeff King p...@peff.net wrote: On Sun, Mar 02, 2014 at 06:04:39AM +0900, Brian Gesiak wrote: My name is Brian Gesiak. I'm a research student at the University of Tokyo, and I'm hoping to participate in this year's Google Summer of Code by contributing to Git. I'm a longtime user, first-time contributor--some of you may have noticed my microproject patches.[1][2] Yes, we did notice them. Thanks, and welcome. :) The ideas page points out that while lock files are closed and unlinked[3] when the program exits[4], object pack files implement their own brand of temp file creation and deletion. This implementation doesn't share the same guarantees as lock files--it is possible that the program terminates before the temp file is unlinked.[5] Lock file references are stored in a linked list. When the program exits, this list is traversed and each file is closed and unlinked. It seems to me that this mechanism is appropriate for temp files in general, not just lock files. Thus, my proposal would be to extract this logic into a separate module--tempfile.h, perhaps. Lock and object files would share the tempfile implementation. That is, both object and lock temp files would be stored in a linked list, and all of these would be deleted at program exit. Yes, I think this is definitely the right way to go. We should be able to unify the tempfile handling for all of git. Once the logic is extracted into a nice API, there are several other places that can use it, too: - the external diff code creates tempfiles and uses its own cleanup routines - the shallow_XX tempfiles (these are not cleaned right now, though I sent a patch recently for them to do their own cleanup) Those are just off the top of my head. There may be other spots, too. It is worth thinking in your proposal about some of the things that the API will want to handle. What are the mismatches in how lockfiles and object files are handled? E.g., how do we finalize them into place? How should the API be designed to minimize race conditions (e.g., if we get a signal delivered while we are committing or cleaning up a file)? Please let me know if this seems like it would make for an interesting proposal, or if perhaps there is something I am overlooking. Any feedback at all would be appreciated. Thank you! You definitely have a grasp of what the project is aiming for, and which areas need to be touched. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 1.9.0 segfault
On Sat, Mar 08, 2014 at 04:46:51PM +, brian m. carlson wrote: On Sat, Mar 08, 2014 at 04:23:43PM +, Guillaume Gelin wrote: Hi, http://pastebin.com/Np7L54ar We're failing to rename because we got an EFAULT, and then we try to print the failing filename, and we get a segfault right here: if (rename(src, dst) 0 !ignore_errors) die_errno (_(renaming '%s' failed), src); I don't know yet if dst is also bad, but clearly src is. I'm looking into it. The problem seems to be that we change argc when we append nested directories to the list and then continue looping over 'source' which has been realloc'd to be larger. But we do not realloc submodule_gitfile at the same time so we start writing beyond the end of the submodule_gitfile array. The particular behaviour of glibc's malloc happens to mean (at least on my system) that this starts overwriting 'src'. This fixes it for me: -- 8 -- diff --git a/builtin/mv.c b/builtin/mv.c index 7e26eb5..23f119a 100644 --- a/builtin/mv.c +++ b/builtin/mv.c @@ -180,6 +180,9 @@ int cmd_mv(int argc, const char **argv, const char *prefix) modes = xrealloc(modes, (argc + last - first) * sizeof(enum update_mode)); + submodule_gitfile = xrealloc(submodule_gitfile, + (argc + last - first) + * sizeof(char *)); } dst = add_slash(dst); -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] builtin/mv: fix out of bounds write
When commit a88c915 (mv: move submodules using a gitfile, 2013-07-30) added the submodule_gitfile array, it was not added to the block that enlarges the arrays when we are moving a directory so that we do not have to worry about it being a directory when we perform the actual move. After this, the loop continues over the enlarged set of sources. Since we assume that submodule_gitfile has size argc, if any of the items in the source directory are submodules we are guaranteed to write beyond the end of submodule_gitfile. Fix this by realloc'ing submodule_gitfile at the same time as the other arrays. Reported-by: Guillaume Gelin cont...@ramnes.eu Signed-off-by: John Keeping j...@keeping.me.uk --- On Sat, Mar 08, 2014 at 06:12:18PM +, John Keeping wrote: This fixes it for me: Here it is as a proper patch. builtin/mv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/builtin/mv.c b/builtin/mv.c index 21c46d1..f99c91e 100644 --- a/builtin/mv.c +++ b/builtin/mv.c @@ -179,6 +179,9 @@ int cmd_mv(int argc, const char **argv, const char *prefix) modes = xrealloc(modes, (argc + last - first) * sizeof(enum update_mode)); + submodule_gitfile = xrealloc(submodule_gitfile, + (argc + last - first) + * sizeof(char *)); } dst = add_slash(dst); -- 1.9.0.6.g037df60.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] builtin/mv: fix out of bounds write
On Sat, Mar 08, 2014 at 06:35:01PM +, John Keeping wrote: When commit a88c915 (mv: move submodules using a gitfile, 2013-07-30) added the submodule_gitfile array, it was not added to the block that enlarges the arrays when we are moving a directory so that we do not have to worry about it being a directory when we perform the actual move. After this, the loop continues over the enlarged set of sources. Since we assume that submodule_gitfile has size argc, if any of the items in the source directory are submodules we are guaranteed to write beyond the end of submodule_gitfile. Fix this by realloc'ing submodule_gitfile at the same time as the other arrays. Reported-by: Guillaume Gelin cont...@ramnes.eu Signed-off-by: John Keeping j...@keeping.me.uk --- On Sat, Mar 08, 2014 at 06:12:18PM +, John Keeping wrote: This fixes it for me: Here it is as a proper patch. builtin/mv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/builtin/mv.c b/builtin/mv.c index 21c46d1..f99c91e 100644 --- a/builtin/mv.c +++ b/builtin/mv.c @@ -179,6 +179,9 @@ int cmd_mv(int argc, const char **argv, const char *prefix) modes = xrealloc(modes, (argc + last - first) * sizeof(enum update_mode)); + submodule_gitfile = xrealloc(submodule_gitfile, + (argc + last - first) + * sizeof(char *)); } dst = add_slash(dst); Yup, that's the same conclusion I came to. There are also two cases where we don't shrink the array properly. I'll rebase my patch on top of this one and send it. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
[PATCH] mv: prevent mismatched data when ignoring errors.
We shrink the source and destination arrays, but not the modes or submodule_gitfile arrays, resulting in potentially mismatched data. Shrink all the arrays at the same time to prevent this. Signed-off-by: brian m. carlson sand...@crustytoothpaste.net --- builtin/mv.c | 5 + 1 file changed, 5 insertions(+) diff --git a/builtin/mv.c b/builtin/mv.c index f99c91e..b20cd95 100644 --- a/builtin/mv.c +++ b/builtin/mv.c @@ -230,6 +230,11 @@ int cmd_mv(int argc, const char **argv, const char *prefix) memmove(destination + i, destination + i + 1, (argc - i) * sizeof(char *)); + memmove(modes + i, modes + i + 1, + (argc - i) * sizeof(char *)); + memmove(submodule_gitfile + i, + submodule_gitfile + i + 1, + (argc - i) * sizeof(char *)); i--; } } else -- 1.9.0.1010.g6633b85.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] builtin/mv: fix out of bounds write
When commit a88c915 (mv: move submodules using a gitfile, 2013-07-30) added the submodule_gitfile array, it was not added to the block that enlarges the arrays when we are moving a directory so that we do not have to worry about it being a directory when we perform the actual move. After this, the loop continues over the enlarged set of sources. Since we assume that submodule_gitfile has size argc, if any of the items in the source directory are submodules we are guaranteed to write beyond the end of submodule_gitfile. Fix this by realloc'ing submodule_gitfile at the same time as the other arrays. Reported-by: Guillaume Gelin cont...@ramnes.eu Signed-off-by: John Keeping j...@keeping.me.uk --- On Sat, Mar 08, 2014 at 07:15:42PM +, brian m. carlson wrote: Yup, that's the same conclusion I came to. There are also two cases where we don't shrink the array properly. I'll rebase my patch on top of this one and send it. Nice catch. While looking at that, I spotted that I forgot to initialize the new values in submodule_gitfile when it grows. Guillaume's test case doesn't catch that because all the subdirectories are submodules. builtin/mv.c | 4 1 file changed, 4 insertions(+) diff --git a/builtin/mv.c b/builtin/mv.c index 21c46d1..5258077 100644 --- a/builtin/mv.c +++ b/builtin/mv.c @@ -179,6 +179,9 @@ int cmd_mv(int argc, const char **argv, const char *prefix) modes = xrealloc(modes, (argc + last - first) * sizeof(enum update_mode)); + submodule_gitfile = xrealloc(submodule_gitfile, + (argc + last - first) + * sizeof(char *)); } dst = add_slash(dst); @@ -192,6 +195,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix) prefix_path(dst, dst_len, path + length + 1); modes[argc + j] = INDEX; + submodule_gitfile[argc + j] = NULL; } argc += last - first; } -- 1.9.0.6.g037df60.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
howto to run git without a master branch
Hi, git newbie here. I would like to work with two main branches: master-g and master-x, instead of the usual master, and apparently git does not like this. After creating a local repository with these two branches, and a server repository with git init --bare, and pushing the two branches: git remote add origin foo@bar:~/path/test.git git push origin master-g git push origin master-x everything seems fine, but cloning: git clone foo@bar:~/path/test.git terminates with a warning: remote HEAD refers to nonexistent ref, unable to checkout. On the original local repository, I have: cat HEAD ref: refs/heads/master-x But on the server repository or the clone repository, HEAD points to master branch, that does not exist: cat HEAD ref: refs/heads/master Replacing in the HEAD file, master by master-g (on the server before cloning, or on the clone after cloning) seems to solve the problem. Shall I worry about this? does my fix (editing directly HEAD on the server) fixes really the problem? what would be the correct procedure to avoid this? Thank you! Carlos Pereira, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
remote rename
Hi, If I have a remote branch origin/topic/foo, running $ git remote rename origin renamed seems to leave directory traces behind: .git/refs/remotes/origin/topic I expected to see .git/refs/remotes/renamed/topic/foo but not .git/refs/remotes/origin. Is this a glitch? I see this with Git 1.9.0. Matan-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Potential GSOC microproject idea
On Mar 3, 2014, at 23:58, Michael Haggerty wrote: list regulars should FEEL ENCOURAGED to submit microprojects to add to the list. (Either submit them as a pull request to the GitHub repository that contains the text [1] or to the mailing list with CC to me.) Potential idea for a microproject: Add a new config setting: user.allowImplicitIdentity Defaults to true. If user.name and GIT_COMMITTER_NAME are unset or user.email and GIT_COMMITTER_EMAIL and EMAIL are unset, an implicit value is substituted for one or both of user.name and user.email. If an automatically generated value is used for both name and email a warning Your name and email address were configured automatically... is displayed. If set to false, no or never, instead of a warning, an error is generated and the operation fails: *** Please tell me who you are. Run git config --global user.email y...@example.com git config --global user.name Your Name to set your account's default identity. Omit --global to set the identity only in this repository. fatal: implicit user identity not allowed the advice portion can be suppressed by setting advice.implicitIdentity to false, but not the fatal: implicit user identity not allowed part. Note that if git config --system --bool user.allowImplicitIdentity false is in effect, it should still be possible to clone (ref logs may be updated, but they should be allowed to use an implicit identity). In other words user.allowImplicitIdentity=false should only inhibit writing any new commit/tag objects that need the current user's name and email when it has not been explicitly provided. I'm not sure how micro this is. :) I do think the amount of code involved is rather small though. Support for something like this has popped up on the list before. Perhaps user.allowAutomaticIdentity and advice.automaticIdentity would be better config names. --Kyle -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] rebase: new convenient option to edit/reword/delete a single commit
Prepare the todo list for you to edit/reword/delete the given commit.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Allowing multiple actions is a bit too much for my shell skills. I
don't really need it so I won't push it, but if somebody gives me a
sketch, I'll try to polish it.
--squash and --fixup would require two commits, making it a bit
awkward in option handling. Or is the fixup/squash always HEAD?
Documentation/git-rebase.txt | 11 +++
git-rebase--interactive.sh | 17 ++---
git-rebase.sh| 22 +-
3 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2a93c64..becb749 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -13,6 +13,7 @@ SYNOPSIS
'git rebase' [-i | --interactive] [options] [--exec cmd] [--onto newbase]
--root [branch]
'git rebase' --continue | --skip | --abort | --edit-todo
+'git rebase' [--edit | -E | --reword | -R | --delete | -D ] commit-ish
DESCRIPTION
---
@@ -356,6 +357,16 @@ unless the `--fork-point` option is specified.
user edit that list before rebasing. This mode can also be used to
split commits (see SPLITTING COMMITS below).
+-E=commit::
+--edit=commit::
+-R=commit::
+--reword=commit::
+-D=commit::
+--delete=commit::
+ Prepare the todo list to edit or reword or delete the
+ specified commit. Configuration variable `rebase.autostash` is
+ ignored.
+
-p::
--preserve-merges::
Instead of ignoring merges, try to recreate them.
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a1adae8..3ded4c7 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -1040,9 +1040,20 @@ fi
has_action $todo ||
die_abort Nothing to do
-cp $todo $todo.backup
-git_sequence_editor $todo ||
- die_abort Could not execute editor
+if test -n $one_action
+then
+ commit=`git rev-parse --short $one_commit`
+ sed 1s/pick $commit /$one_action $commit / $todo $todo.new ||
+ die_abort failed to update todo list
+ grep ^$one_action $commit $todo.new /dev/null ||
+ die_abort expected to find '$one_action $commit' line but did
not
+ mv $todo.new $todo ||
+ die_abort failed to update todo list
+else
+ cp $todo $todo.backup
+ git_sequence_editor $todo ||
+ die_abort Could not execute editor
+fi
has_action $todo ||
die_abort Nothing to do
diff --git a/git-rebase.sh b/git-rebase.sh
index 5f6732b..2acffb4 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -32,6 +32,9 @@ verify allow pre-rebase hook to run
rerere-autoupdate allow rerere to update index with resolved conflicts
root! rebase all reachable commits up to the root(s)
autosquash move commits that begin with squash!/fixup! under -i
+E,edit=! generate todo list to edit this commit
+R,reword=! generate todo list to reword this commit's message
+D,delete=! generate todo list to delete this commit
committer-date-is-author-date! passed to 'git am'
ignore-date! passed to 'git am'
whitespace=! passed to 'git apply'
@@ -228,6 +231,7 @@ then
fi
test -n $type in_progress=t
+one_action=
total_argc=$#
while test $# != 0
do
@@ -290,6 +294,7 @@ do
;;
--autostash)
autostash=true
+ explicit_autosquash=t
;;
--verbose)
verbose=t
@@ -335,6 +340,13 @@ do
--gpg-sign=*)
gpg_sign_opt=-S${1#--gpg-sign=}
;;
+ --edit=*|--reword=*|--delete=*)
+ test -n $one_action die $(gettext --edit, --reword or
--delete cannot be used multiple times)
+ interactive_rebase=explicit
+ one_action=${1%=*}
+ one_action=${one_action#--}
+ one_commit=${1#--*=}
+ ;;
--)
shift
break
@@ -342,6 +354,7 @@ do
esac
shift
done
+test -n $one_action test $# -gt 0 usage
test $# -gt 2 usage
if test -n $cmd
@@ -438,7 +451,14 @@ else
state_dir=$apply_dir
fi
-if test -z $rebase_root
+if test -n $one_action
+then
+ upstream_name=$one_commit^
+ upstream=$(peel_committish ${upstream_name}) ||
+ die $(eval_gettext invalid upstream \$upstream_name)
+ upstream_arg=$upstream_name
+ test -n $explicit_autosquash || autosquash=
+elif test -z $rebase_root
then
case $# in
0)
--
1.9.0.40.gaa8c3ea
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: howto to run git without a master branch
On 2014-03-08 22.37, Carlos Pereira wrote: Hi, git newbie here. I would like to work with two main branches: master-g and master-x, instead of the usual master, and apparently git does not like this. After creating a local repository with these two branches, and a server repository with git init --bare, and pushing the two branches: git remote add origin foo@bar:~/path/test.git git push origin master-g git push origin master-x everything seems fine, but cloning: git clone foo@bar:~/path/test.git terminates with a warning: remote HEAD refers to nonexistent ref, unable to checkout. This is because Git is trying to be nice: When you clone, it tries to checkout a branch for you. What happens when you only have 1 branch, lets say master-x? If I clone the bare repo here, with only 1 branch, this branch is automatically checked out (tested on 1.8.5.2) What happens when you have 2 branches on the server? Git really can not make a decision which one is the right one to check out for you, so if you have 2 branched like master and develop, it checks out the master branch for you. But if you have master-x and master-g then Git has no clue, which one could be you favorite one (and neither have I) What does git branch say? (I think nothing) What does git branch -r say? (I think origin/master-g and origin/master-x) On the original local repository, I have: cat HEAD ref: refs/heads/master-x But on the server repository or the clone repository, HEAD points to master branch, that does not exist: cat HEAD ref: refs/heads/master Replacing in the HEAD file, master by master-g (on the server before cloning, or on the clone after cloning) seems to solve the problem. Shall I worry about this? does my fix (editing directly HEAD on the server) fixes really the problem? No what would be the correct procedure to avoid this? (Don't worry if there is a warning, when Git tries to be nice) (Or feel free to send a patch to this list which improves the user experience) Thank you! Carlos Pereira, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] commit.c: Replace starts_with() with skip_prefix()
On Fri, Mar 7, 2014 at 5:49 AM, karthik nayak karthik@gmail.com wrote:
Hello Eric,
Thanks for your reply, and for that information. should i patch again or
this should do?
And what next? Talk to the mentor?
The ultimate authority deciding if a patch is ready is Junio, as it
would have to be accepted into his tree. Since he already accepted a
similar patch from a different potential GSoC applicant, it may not
make sense to refine this one further. What is important is that you
are now familiar with the review process on this project, and the
mentors (hopefully) have gained insight into your abilities and how
you interact with reviewers (which was the goal of these
microprojects).
Probably best at this point is to consider a proposed project [1] or
choose your own, and start the task of applying for a GSoC position
(by whatever means that is done).
[1]: https://github.com/git/git.github.io/blob/master/SoC-2014-Ideas.md
On Fri, Mar 7, 2014 at 3:04 PM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Thu, Mar 6, 2014 at 12:05 PM, Karthik Nayak karthik@gmail.com
wrote:
Replace all instances of starts_with() by skip_prefix(),
which can not only be used to check presence of a prefix,
but also used further on as it returns the string after the prefix,
if the prefix is present. And also manages to do, what the current
code does in two steps.
Better. Thanks.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
Hello Eric,
In this patch, I have:
1. Fixed the improper placement of buf_date , initialised to a NULL
string.
2. Fixed whitespace.
3. Better naming as per your suggestion.
4. Fixed the initilisation before the if statement.
Thanks for your suggestion.
---
commit.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/commit.c b/commit.c
index 6bf4fe0..4144e00 100644
--- a/commit.c
+++ b/commit.c
@@ -553,6 +553,7 @@ static void record_author_date(struct
author_date_slab *author_date,
struct ident_split ident;
char *date_end;
unsigned long date;
+ const char *buf_date;
if (!commit-buffer) {
unsigned long size;
@@ -565,15 +566,15 @@ static void record_author_date(struct
author_date_slab *author_date,
for (buf = commit-buffer ? commit-buffer : buffer;
buf;
buf = line_end + 1) {
+ buf_date = skip_prefix(buf, author );
The data after author is identification information (name, email),
not date. In fact, this information gets passed to the function
split_ident_line(), so a better name for this variable is 'ident_line'
(but not the misspelling 'indent_line' from one of your earlier
attempts).
line_end = strchrnul(buf, '\n');
- if (!starts_with(buf, author )) {
+ if (!buf_date) {
if (!line_end[0] || line_end[1] == '\n')
return; /* end of header */
continue;
}
- if (split_ident_line(ident,
-buf + strlen(author ),
-line_end - (buf + strlen(author
))) ||
+ if (split_ident_line(ident, buf_date,
+line_end - buf_date) ||
!ident.date_begin || !ident.date_end)
goto fail_exit; /* malformed author line */
break;
@@ -1098,6 +1099,7 @@ int parse_signed_commit(const unsigned char *sha1,
char *buffer = read_sha1_file(sha1, type, size);
int in_signature, saw_signature = -1;
char *line, *tail;
+ const char *gpg_sig;
if (!buffer || type != OBJ_COMMIT)
goto cleanup;
@@ -1113,9 +1115,9 @@ int parse_signed_commit(const unsigned char *sha1,
next = next ? next + 1 : tail;
if (in_signature line[0] == ' ')
sig = line + 1;
- else if (starts_with(line, gpg_sig_header)
-line[gpg_sig_header_len] == ' ')
- sig = line + gpg_sig_header_len + 1;
+ else if ((gpg_sig = skip_prefix(line, gpg_sig_header))
+ gpg_sig[0] == ' ')
+ sig = gpg_sig + 1;
Other than the poor variable name 'buf_date' and the review comments
by Junio and Tanay that this particular change is of questionable
value and perhaps should be dropped, this version of the patch looks
reasonable.
Thanks.
if (sig) {
strbuf_add(signature, sig, next - sig);
saw_signature = 1;
@@ -1193,10 +1195,8 @@ static void parse_gpg_output(struct
signature_check *sigc)
for (i = 0; i ARRAY_SIZE(sigcheck_gpg_status); i++) {
