What's causing this? I'm using stgit on the master branch.

I'm fixing it each time on the remote server by deleting the ref to master.
jonsmirl@terra:~/ds$ git push digispeaker

To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git

 ! [rejected]        master -> master (non-fast forward)

error: failed to push to

'ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git'

jonsmirl@terra:~/ds$
On the server I have:

[core]

        repositoryformatversion = 0

        filemode = true

        bare = true

        logallrefupdates = true
bare was set false, I just flipped it to true. The server repo was

originally created via a clone from kernel.org and then renamed to be

a bare repo. Why do we need a 'bare' attribute?
--

Jon Smirl

jonsmirl@gmail.com

-

A "non-fast forward" means that you had this history earlier:
         o---o---A

        /

    ---o
pushed "A" to the remote's 'master', then built this history:
         o---o---A

        /

    ---o---o---o---o---A'
by rewinding and rebuilding, and the tip of the branch now

points at A', which you tried to push to the remote.
Which often causes troubles for people who are fetching from the

branch you are pushing into, and forbidden by default as a

safety measure.
As long as the people who fetch from the branch knows that you

will regularly rewinding the tip of the branch, there is no

confusion, and you can "force" a non-fast forward update.  There

are two independent safety mechanisms:
 - the sending end safety can be overriden by "git push --force"

   and/or by using a refspec prefixed with a '+');
 - the receiving end safety can be overriden by the config

   variable receive.denynonfastworwards of the repository you

   are pushing into.
The latter defaults to "unsafe", but if the safety is activated

in the repository, forcing from the sending side will not

deactivate it.  IOW, both ends need to agree to allow the unsafe
There are a few things that change behaviour depending on the

bareness of the repository.  One example is that "git fetch"

that updates to the current branch (i.e. what HEAD points at) by

having it as the RHS of a refspec is accepted only for bare

repositories (for non-bare repositories such a fetch would make

the HEAD and the work tree go out-of-sync).

-

stgit must be doing this when I rebase. It pops all of it's patches,

moves to head of linus/master and then rebases them.
What is the right way to share repositories using stgit? I have a set

of patches which I am working on for kernel inclusion. I have them

applied as a stgit stack on top of linus/master. I need to share this

patch stack with other developers. These developers may want to change

one of my patches. Right now they are emailing me deltas and I apply

them to the appropriate stgit patch. I have seventeen patches in my

stack currently.
I am starting to see why several people have made comments about

integrating stgit into git. When other developers clone my repo the

stgit setup doesn't come with it. It would be great it we could use
--

Jon Smirl

jonsmirl@gmail.com

-

StGIT is meant for keeping a clean history but with the big

disadvantage that this history is volatile.
A solution is for the other developers to use StGIT or just git-rebase

so that they always have the same base (volatile) history and keep

their patches on top of yours.
A 2nd approach is to use topic branches rather than StGIT patches but

you might lose some flexibility.
Yet another approach (which I used) is to keep a public branch (can be

maintained by StGIT) where the history doesn't change and a devel

volatile branch. When I modify some patches and they are ready for

publishing, switch to the public branch and cherry-pick them (stg

pick) from the devel branch. Because this is done with a three-way

merge in StGIT, you will only get the new changes rather than the full

patch. You need to change the patch message (as it is that of the

original patch) to describe the specific changes and run 'stg refresh

&& stg commit' to store it into the immutable history (well, there is

an 'uncommit' command as well if something goes wrong).
--

Catalin

-

Is a StGit where we can transparently share patches under version

control in the works?
Something like this:

clone repo with stgit

normal stg commands work with no setup

change a patch

stg push the repo
I stg pull and the patch is updated.

I also get rebased forward if the base repo has been updated
--

Jon Smirl

jonsmirl@gmail.com

-

I've been thinking vaguely about support for essentially version

controlling a quilt series, with the fundamental idea being that the

history of the branch you're working on is a sequence of states of the

series, with magic for having both the series specification and the final

state in each commit.
Note that this is a different concept from stgit (and, I think, guilt),

which uses the git engine as the magic behind the quilt-like operation,

meaning that the history of the commit at the end of the series goes back

through the patches in the series, not back through the changes to the

series.
I've got a bunch of ideas on the subject, but I don't really have the

quilt experience to know how to make this useful to people who want to do

this kind of thing. My dream, from the perspective of a user of the

results of somebody else's use of this feature, would be being able to

bisect -mm to determine first that -mm stopped working when Andrew updated

a particular tree, and then bisect within that tree (in each case

generating the test tree with the complete -mm series, but with that

tree's patch series being from the test point).
	-Daniel

*This .sig left intentionally blank*

-

the branch you are pushing does not fast-forward to the one on

digispeaker. IOW, the master on digispeaker has changed since you made

changes on your local master.
-

Alex, are you going to rework your "consolidate nonff errors and print a

more extended message" patch on top of what's in next (I think it should

be much simpler now).
-Peff

-

Do you mean that "Beautify the output of send-pack a bit", Message-ID:

<20071112221140.GD2918@steel.home>?
If so, I'm confused. Didn't you already do that in your recent

"send-pack:" patch series? It looked to me as if you did (except for

the hint regarding non-ff branches to be updated everything is there).
-

That is what I meant. In the current code, the errors aren't

consolidated at the end, and as you mentioned, we don't print the extra

message. Two patch series follows (but see comments on each patch).
-Peff

-

If there were refs rejected for not being fastforwards, then

we used to print a "maybe you are not up-to-date" hint. This

was lost in the recent terse-output patches.
Signed-off-by: Jeff King <peff@peff.net>

---

I am slightly negative on this patch, just because I always found that

particular warning a bit ugly (and the new output is so nice and

compact). But for new users, perhaps the extra hint is helpful?
If we do want the warning, then other options include:

  - listing each non-fast forward, as Alex's original patch did; this

    seems kind of pointless given that they are clustered at the bottom

    already

  - possibly cluster non-fast forwards differently from other errors in

    the output

  - tweak the text
 builtin-send-pack.c |    9 +++++++++

 1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c

index f1cdb97..4bfa847 100644

--- a/builtin-send-pack.c

+++ b/builtin-send-pack.c

@@ -341,6 +341,7 @@ static void print_push_status(const char *dest, struct ref *refs)

 {

 	struct ref *ref;

 	int n = 0;

+	int nonff = 0;
 	if (args.verbose) {

 		for (ref = refs; ref; ref = ref->next)

@@ -357,7 +358,15 @@ static void print_push_status(const char *dest, struct ref *refs)

 		    ref->status != REF_STATUS_UPTODATE &&

 		    ref->status != REF_STATUS_OK)

 			n += print_one_push_status(ref, dest, n);

+		if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD)

+			nonff++;

 	}

+

+	if (nonff)

+		error("%d remote refs were not ancestors of their "

+		      "corresponding local ref\n"

+		      "Maybe you are not up-to-date and need to pull first?",

+		      nonff);

 }
 static int refs_pushed(struct ref *ref)

--

1.5.3.6.1784.gd1b1d-dirty

-

Dunno. It's kind of dumb hint and it takes lots of space. I was even

thinking about hint(const char *,...), which can be configured to

compile out in Makefile.
-

Instead of intermingling success and failure, we now print:
  1. all uptodate refs (if args.verbose is enabled)

  2. successfully pushed refs

  3. failed refs
with the assumption that the user is most likely to see the

ones at the end, and therefore we order them from "least

interesting" to "most interesting."
Signed-off-by: Jeff King <peff@peff.net>

---

I am somewhat ambivalent on this patch. In most cases, it won't make a

difference, since the output is small enough. For large pushes, it might

be better to have errors at the end. OTOH, you do still get "error:

failed to push to ..." at the end, and you can scroll up and see the

errors if you like. And it's not like preserving the original ref output

order was all that interesting.
 builtin-send-pack.c |   93 +++++++++++++++++++++++++++++----------------------

 1 files changed, 53 insertions(+), 40 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c

index 3ce218f..f1cdb97 100644

--- a/builtin-send-pack.c

+++ b/builtin-send-pack.c

@@ -298,52 +298,65 @@ static void print_ok_ref_status(struct ref *ref)

 	}

 }
+static int print_one_push_status(struct ref *ref, const char *dest, int count)

+{

+	if (!count)

+		fprintf(stderr, "To %s\n", dest);

+

+	switch(ref->status) {

+	case REF_STATUS_NONE:

+		print_ref_status('X', "[no match]", ref, NULL, NULL);

+		break;

+	case REF_STATUS_REJECT_NODELETE:

+		print_ref_status('!', "[rejected]", ref, NULL,

+				"remote does not support deleting refs");

+		break;

+	case REF_STATUS_UPTODATE:

+		print_ref_status('=', "[up to date]", ref,

+				ref->peer_ref, NULL);

+		break;

+	case REF_STATUS_REJECT_NONFASTFORWARD:

+		print_ref_status('!', "[rejected]", ref, ref->peer_ref,

+				"non-fast forward");

+		break;

+	case REF_STATUS_REMOTE_REJECT:

+		print_ref_status('!', "[remote rejected]", ref,

+				ref->deletion ? ref->peer_ref : NULL,

+				ref->remote_status);

+		break;

+	case REF_STATUS_EXPECTING_REPORT:

+		print_ref_status('!', "[remo...
[ message continues ]

Eh,... in ref->deletion mode, the peer_ref is...

-

Gah, sorry. This crept in because I based it on the previous, broken

version of the other patch series which had the same problem (and

obviously this chunk is just a pure code move + reindent).
But pretend like it was competently prepared and give your comments on

the idea. ;)
-Peff

-

You will also find that it doesn't apply cleanly to 'next', since it

attempts to remove the bogus version of the lines (while you correctly

fixed them up when you applied to 'next').
Below is a fixed version of the patch for convenience.
-- >8 --

send-pack: cluster ref status reporting
Instead of intermingling success and failure, we now print:
  1. all uptodate refs (if args.verbose is enabled)

  2. successfully pushed refs

  3. failed refs
with the assumption that the user is most likely to see the

ones at the end, and therefore we order them from "least

interesting" to "most interesting."

---

 builtin-send-pack.c |   93 +++++++++++++++++++++++++++++----------------------

 1 files changed, 53 insertions(+), 40 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c

index 3aab89c..25ae1fe 100644

--- a/builtin-send-pack.c

+++ b/builtin-send-pack.c

@@ -298,52 +298,65 @@ static void print_ok_ref_status(struct ref *ref)

 	}

 }
+static int print_one_push_status(struct ref *ref, const char *dest, int count)

+{

+	if (!count)

+		fprintf(stderr, "To %s\n", dest);

+

+	switch(ref->status) {

+	case REF_STATUS_NONE:

+		print_ref_status('X', "[no match]", ref, NULL, NULL);

+		break;

+	case REF_STATUS_REJECT_NODELETE:

+		print_ref_status('!', "[rejected]", ref, NULL,

+				"remote does not support deleting refs");

+		break;

+	case REF_STATUS_UPTODATE:

+		print_ref_status('=', "[up to date]", ref,

+				ref->peer_ref, NULL);

+		break;

+	case REF_STATUS_REJECT_NONFASTFORWARD:

+		print_ref_status('!', "[rejected]", ref, ref->peer_ref,

+				"non-fast forward");

+		break;

+	case REF_STATUS_REMOTE_REJECT:

+		print_ref_status('!', "[remote rejected]", ref,

+				ref->deletion ? NULL : ref->peer_ref,

+				ref->remote_status);

+		break;

+	case REF_STATUS_EXPECTING_REPORT:

+		print_ref_status('!', "[remote failure]", ref,

+				ref->deletion ? NULL : ref->peer_ref,

+				"remote failed to report status");

+		break;

+	case REF_STATUS_...
[ message continues ]

Heh, at least I've privately queued it at the tip of

jk/send-pack for review but not merged it to 'next' yet, after

fixing it up (the last round I also fixed up so that was partly

why I noticed -- the patch did not apply).
The idea feels sound, and code under cursory look was fine.

-

OK, good. I should have noticed because I also ran across the same patch

failure when I did a rebase earlier today, but I didn't consider that
I think it is probably worth applying then. It is slightly more useful

to the user, and I haven't been able to see any downside.
-Peff

-

I vote for this. The non-ff refs clustered together was the real
It is just simplier to distinguish visually: non-ff's are formatted

significantly different. You don't even have to read what is written

to immediately notice if there are problems.
-