git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* Trying to Update All Heads of a Repository
@ 2005-11-04  0:23  5% Jon Loeliger
  0 siblings, 0 replies; 5+ results
From: Jon Loeliger @ 2005-11-04  0:23 UTC (permalink / raw)
  To: git


Guys and Gals,

*sigh*

This is the sort of thing that mystifies me still.
I think there is (should be?) an easy command and
I just missed that day in class.  Feel free to
smack me with the obvious as needed...

I re-cloned (rsync) by git.git tree yesteday.
Today is a new day, and I want to start with
a fresh update of the entire git.git tree.
I have not changed anything in my copy yet.
My goal is a simple update of the entire repository.

    % git --version
    git version 0.99.9.GIT

Uh, foo.  That's a version from 02-Nov-2005.  I guess I could
dig out a SHA1 and we'd know exactly what version it is.

(Request:  Does it make sense to have a hard SHA1 as
           part of git's output version string?)

First, I have this, because it came with a git-clone:

    % cat .git/remotes/origin
    URL: rsync://rsync.kernel.org/pub/scm/git/git.git
    Pull: master:origin

I don't know how to say "Grab all the updates for
all the heads for which I have heads in my .git/refs".

So I hope "git pull --help" will tell me:

    % git pull --help
    usage: git-fetch-pack [-q] [-v] [--exec=upload-pack] [host:]directory <refs>...
    Fetch failure: --help

That would be no.  So I hit the man page, and I can't
quite decipher it.  I'm dense, so I have to re-read it
a few more times until I fully grok it.  Dinner interferes.

Like could I have just said?:

    % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git
or
    % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git master:origin
    % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git pu:pu
    % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git todo:todo

Dunno yet.


In the meantime, I figure I can effectively achieve my
goal by:

    for each head $h
        git checkout -f $h
        git pull rsync://rsync.kernel.org/pub/scm/git/git.git $h:$h

So I start with master.  I know I can cheat here and rely
on the "Pull: master:origin":

    % git pull origin
    receiving file list ... done

    sent 102 bytes  received 12339 bytes  8294.00 bytes/sec
    total size is 4708148  speedup is 378.44
    * committish: a3114b3428595710d4719dd668531210af5993c9
      branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git
    * refs/heads/origin: same as branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git
    Already up-to-date.

That worked fine:

    % git show-branch | head -15
    ! [maint] GIT 0.99.9b
     * [master] Document --since and --until options to rev-parse.
      ! [origin] Document --since and --until options to rev-parse.
       ! [pu] Merge branch 'master'
	! [todo] GIT 0.99.9
    -----
	+ [todo] GIT 0.99.9
	+ [todo^] 2005-10-26 (prepare for 0.99.9)
	+ [todo~2] Update 2005-10-19 afternoon.
	+ [todo~3] 2005-10-18 midnight
	+ [todo~4] 2005-10-16 early afternoon.
	+ [todo~5] 2005-10-16 midnight.
	+ [todo~6] Updates 2005-10-14 night
	+ [todo~7] Updates 2005-10-12 night.

On to the pu branch:

    % git checkout -f pu
    % git show-branch | head -10
    ! [maint] GIT 0.99.9b
     ! [master] Document --since and --until options to rev-parse.
      ! [origin] Document --since and --until options to rev-parse.
       * [pu] Merge branch 'master'
	! [todo] GIT 0.99.9
    -----
	+ [todo] GIT 0.99.9
	+ [todo^] 2005-10-26 (prepare for 0.99.9)
	+ [todo~2] Update 2005-10-19 afternoon.
	+ [todo~3] 2005-10-18 midnight

And pull it now:

    % git pull rsync://rsync.kernel.org/pub/scm/git/git.git pu:pu

    receiving file list ... done

    sent 102 bytes  received 12325 bytes  8284.67 bytes/sec
    total size is 4708148  speedup is 378.86
    * committish: 6c86914344ea64e3a7b287721bdeaa7d41f8a1c3
      branch 'pu' of rsync://rsync.kernel.org/pub/scm/git/git
    * refs/heads/pu: does not fast forward to branch 'pu' of rsync://rsync.kernel.org/pub/scm/git/git;
      not updating.
    Trying really trivial in-index merge...
    fatal: Merge requires file-level merging
    Nope.
    Trying simple merge.
    Simple merge failed, trying Automatic merge.
    Auto-merging Makefile.
    ERROR: git-merge-ours.sh: Not handling case  -> a64704f3e52be43b427792ef9c1bbe42af057c87 -> 4f3d053889de4a5ba8e6e5d519c014a51220accd
    fatal: merge program failed
    Automatic merge failed; fix up by hand

Rats.  But why did this fail?  I've changed nothing in my tree.
I'm pulling remote pu into local pu directly.  I think this
should Just Work...

Uh, now what?

    % git status

    # On branch refs/heads/pu
    #
    # Updated but not checked in:
    #   (will commit)
    #
    #       new file: Documentation/git-http-push.txt
    #       modified: Documentation/git-rev-parse.txt
    #       modified: Makefile
    #       modified: commit.c
    #       modified: config.c
    #       modified: fetch-pack.c
    #       modified: git-branch.sh
    #       modified: git-checkout.sh
    #       unmerged: git-merge-ours.sh
    #       modified: git-push.sh
    #       new file: git-shallow-pack.sh
    #       modified: git-svnimport.perl
    #       new file: http-push.c
    #       modified: ls-files.c
    #       modified: name-rev.c
    #       modified: send-pack.c
    #       modified: server-info.c
    #       modified: sha1_name.c
    #       modified: t/t3001-ls-files-others-exclude.sh
    #       modified: tag.c
    #       modified: tag.h
    #       modified: upload-pack.c
    #
    #
    # Changed but not updated:
    #   (use git-update-index to mark for commit)
    #
    #       unmerged: git-merge-ours.sh
    #
    #
    # Untracked files:
    #   (use "git add" to add to commit)
    #
    #       git-merge-ours.sh

    % git diff
    * Unmerged path git-merge-ours.sh

    % cat .git/HEAD
    0e6a92bd0b33b3461fb7b7f7eb34647ad93d451d

    % cat .git/FETCH_HEAD
    6c86914344ea64e3a7b287721bdeaa7d41f8a1c3                branch 'pu' of rsync://rsync.kernel.org/pub/scm/git/git

So.  Yes, I know I can "git-add git-merge-ours.sh" and then
do a "git-update-index git-merge-ours.sh" and get a spiffy
new index.  And then I can "git-commit" it all, and that
should be everything.

But I really thought that this should Just Work?
Shouldn't this be a fast forward, nice-n-clean-n-easy?

Do I need to add .git/remote entries for each head?
Can I place multiple "Pull: pu:pu" type refspecs into
the one .git/remote/origin?  Is that what people do?
Even if that I do that, I still have to manually iterate:

    for each head $h
        git checkout -f $h
        git pull origin $h

More tequilla.

Thanks,
jdl

^ permalink raw reply	[relevance 5%]

* git 0.99.9b installed on kernel.org
@ 2005-11-02 16:52 14% H. Peter Anvin
  0 siblings, 0 replies; 5+ results
From: H. Peter Anvin @ 2005-11-02 16:52 UTC (permalink / raw)
  To: Git Mailing List

git 0.99.9b is now installed on all kernel.org machines.

	-hpa

^ permalink raw reply	[relevance 14%]

* Re: GIT 0.99.9b
  2005-11-02  7:25  7% GIT 0.99.9b Junio C Hamano
@ 2005-11-02  9:19  7% ` Martin Langhoff
  0 siblings, 0 replies; 5+ results
From: Martin Langhoff @ 2005-11-02  9:19 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On 11/2/05, Junio C Hamano <junkio@cox.net> wrote:
> The second maintenance release of 0.99.9 series is found at the
> usual place.  0.99.9a was purely to work around RPM build
> issues; this one contains all the good changes in the master
> branch -- mostly documentation updates, with some cvsimport
> fixes from Martin.

Great! Thanks and kudos for the swift merge. *Really* looking forward for 1.0

cheers,


martin

^ permalink raw reply	[relevance 7%]

* GIT 0.99.9b
@ 2005-11-02  7:25  7% Junio C Hamano
  2005-11-02  9:19  7% ` Martin Langhoff
  0 siblings, 1 reply; 5+ results
From: Junio C Hamano @ 2005-11-02  7:25 UTC (permalink / raw)
  To: git; +Cc: linux-kernel, hpa

The second maintenance release of 0.99.9 series is found at the
usual place.  0.99.9a was purely to work around RPM build
issues; this one contains all the good changes in the master
branch -- mostly documentation updates, with some cvsimport
fixes from Martin.

The workaround for building RPMs has not changed since 0.99.9a,
mainly because I haven't heard back if it was good enough for
kernel.org consumption, or otherwise what changes are needed.

Note that package split we discussed earlier is not something I
consider "needed"; it is more like "nice to have before 1.0".  I
am hoping 0.99.9b to hit kernel.org machines soon, so people do
not have to be bitten by 0.99.8f glitches as reported for the
last couple of days.

That is, provided if the RPM workaround in 0.99.9a and this one
is good enough to produce an installable package, of course.

^ permalink raw reply	[relevance 7%]

* [PATCH] Add --no-commit to git-merge/git-pull.
@ 2005-11-02  3:43  4% Junio C Hamano
  0 siblings, 0 replies; 5+ results
From: Junio C Hamano @ 2005-11-02  3:43 UTC (permalink / raw)
  To: git

With --no-commit flag, git-pull will perform the merge but pretends as
if the merge needed a hand resolve even if automerge cleanly resolves,
to give the user a chance to add further changes and edit the commit
message.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 This turns out to be useful while maintaining the maint branch
 for 0.99.9[a-z] lettered maintenance releases.  The plan is for
 the contents of that branch to match always the tip of the
 master branch during 0.99.9 timeframe, and every time a merge
 is done from master into maint, only GIT_VERSION in the
 Makefile is bumped up.  0.99.8 maintenance branch was done by
 pulling from a private branch "fixes", immediately followed by
 a separate commit to bump that definition up, but with this, I
 could instead do this:

        $ git checkout master
        $ git am -3 -s ./++patches-from-the-list.mbox
	... work work work in master ...
        $ git checkout maint
        $ git pull --no-commit . master
        ... update the version in Makefile and debian/changelog ...
        $ git commit -a -m 'GIT 0.99.9b'

 git-merge.sh |   28 ++++++++++++++++++----------
 git-pull.sh  |    6 ++++--
 2 files changed, 22 insertions(+), 12 deletions(-)

applies-to: 60d390a285756ba840953418954ac05dca40f75b
c575e6d759f2305e5710dae7ac58274db5930de7
diff --git a/git-merge.sh b/git-merge.sh
index 6ad96eb..dd104db 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -9,7 +9,7 @@ LF='
 '
 
 usage () {
-    die "git-merge [-n] [-s <strategy>]... <merge-message> <head> <remote>+"
+    die "git-merge [-n] [--no-commit] [-s <strategy>]... <merge-message> <head> <remote>+"
 }
 
 # all_strategies='resolve recursive stupid octopus'
@@ -63,6 +63,8 @@ do
 	-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
 		--no-summa|--no-summar|--no-summary)
 		no_summary=t ;;
+	--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
+		no_commit=t ;;
 	-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
 		--strateg=*|--strategy=*|\
 	-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -111,18 +113,18 @@ done
 common=$(git-show-branch --merge-base $head "$@")
 echo "$head" >"$GIT_DIR/ORIG_HEAD"
 
-case "$#,$common" in
-*,'')
+case "$#,$common,$no_commit" in
+*,'',*)
 	# No common ancestors found. We need a real merge.
 	;;
-1,"$1")
+1,"$1",*)
 	# If head can reach all the merge then we are up to date.
 	# but first the most common case of merging one remote
 	echo "Already up-to-date."
 	dropsave
 	exit 0
 	;;
-1,"$head")
+1,"$head",*)
 	# Again the most common case of merging one remote.
 	echo "Updating from $head to $1."
 	git-update-index --refresh 2>/dev/null
@@ -132,11 +134,11 @@ case "$#,$common" in
 	dropsave
 	exit 0
 	;;
-1,?*"$LF"?*)
+1,?*"$LF"?*,*)
 	# We are not doing octopus and not fast forward.  Need a
 	# real merge.
 	;;
-1,*)
+1,*,)
 	# We are not doing octopus, not fast forward, and have only
 	# one common.  See if it is really trivial.
 	echo "Trying really trivial in-index merge..."
@@ -210,12 +212,18 @@ do
     # Remember which strategy left the state in the working tree
     wt_strategy=$strategy
 
-    git-merge-$strategy $common -- "$head_arg" "$@" || {
+    git-merge-$strategy $common -- "$head_arg" "$@"
+    exit=$?
+    if test "$no_commit" = t && test "$exit" = 0
+    then
+	exit=1 ;# pretend it left conflicts.
+    fi
+
+    test "$exit" = 0 || {
 
 	# The backend exits with 1 when conflicts are left to be resolved,
 	# with 2 when it does not handle the given merge at all.
 
-	exit=$?
 	if test "$exit" -eq 1
 	then
 	    cnt=`{
@@ -272,4 +280,4 @@ do
 done >"$GIT_DIR/MERGE_HEAD"
 echo $merge_msg >"$GIT_DIR/MERGE_MSG"
 
-die "Automatic merge failed; fix up by hand"
+die "Automatic merge failed/prevented; fix up by hand"
diff --git a/git-pull.sh b/git-pull.sh
index d476518..9601627 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -10,13 +10,15 @@ usage () {
     die "git pull [-n] [-s strategy]... <repo> <head>..."
 }
 
-strategy_args= no_summary=
+strategy_args= no_summary= no_commit=
 while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
 do
 	case "$1" in
 	-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
 		--no-summa|--no-summar|--no-summary)
 		no_summary=-n ;;
+	--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
+		no_commit=--no-commit ;;
 	-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
 		--strateg=*|--strategy=*|\
 	-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -81,4 +83,4 @@ case "$strategy_args" in
 esac
 
 merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
-git-merge $no_summary $strategy_args "$merge_name" HEAD $merge_head
+git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
---
0.99.9.GIT

^ permalink raw reply related	[relevance 4%]

Results 1-5 of 5 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2005-11-02  3:43  4% [PATCH] Add --no-commit to git-merge/git-pull Junio C Hamano
2005-11-02  7:25  7% GIT 0.99.9b Junio C Hamano
2005-11-02  9:19  7% ` Martin Langhoff
2005-11-02 16:52 14% git 0.99.9b installed on kernel.org H. Peter Anvin
2005-11-04  0:23  5% Trying to Update All Heads of a Repository Jon Loeliger

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).