4 ms·

"Git standard workflow"? Where'd you get that notion from? Supposing there is one, care to share?

ubernostrum 17y ago
Where'd you get that notion from? From the documentation and from the fact that pretty much every git user who's responded has told me the same things. Or am I supposed to take that as a massive coincidence?
- unbracketed 17y ago
  You didn't specify your sample size and I won't vouch for what people I don't know tell you. You can take it as whatever you'd like. Next you'll be saying the Django tutorial is the standard way to lay out projects. It's in the documentation, right?
  - ubernostrum 17y ago
    Well, of the people who decided to provide answers on HN or reddit, the consensus was: merge the branch, delete it, then add a tag on the merge commit. And then on IRC the author of this book told me to do the same thing: http://pragprog.com/titles/tsgit/pragmatic-version-control-using-git http://pragprog.com/titles/tsgit/pragmatic-version-control-u... The only person who suggested anything else, out of fifty-seven comments so far, was one who suggested merging the branch and then keeping it around rather than deleting and tagging it. Since that's all I have to go on, and since it seems to be a pretty clear consensus, I'm taking their advice as being a generally-accepted convention amongst git users. Granted, such conventions in git seem to be as ephemeral as branches (e.g., fads such as "rebase everything! rebase after every commit! No, wait, never rebase! Rebasing is evil! Nobody should rebase!"), but if you're trying to suggest that as a result there are no conventions, I'm just going to write you off.
    - hyperbolist 17y ago
      Conventions are just conventions anyway. We've established that there's no technical barrier to your two objections. 1) You can clone different branches into different paths, which is exactly like a traditional svn workflow, and a pretty normal thing to do for continuous integrations and the like. 2) And if you never want to delete a branch, you can check on their merged status to determine if they're "done". More clever solutions have been supplied by others in this thread. You needn't convert to git, but it'd be polite to recognize that your objection to git is purely psychological.

Where'd you get that notion from? From the documentation and from the fact that pretty much every git user who's responded has told me the same things. Or am I supposed to take that as a massive coincidence?

unbracketed 17y ago
You didn't specify your sample size and I won't vouch for what people I don't know tell you. You can take it as whatever you'd like. Next you'll be saying the Django tutorial is the standard way to lay out projects. It's in the documentation, right?
- ubernostrum 17y ago
  Well, of the people who decided to provide answers on HN or reddit, the consensus was: merge the branch, delete it, then add a tag on the merge commit. And then on IRC the author of this book told me to do the same thing: http://pragprog.com/titles/tsgit/pragmatic-version-control-using-git http://pragprog.com/titles/tsgit/pragmatic-version-control-u... The only person who suggested anything else, out of fifty-seven comments so far, was one who suggested merging the branch and then keeping it around rather than deleting and tagging it. Since that's all I have to go on, and since it seems to be a pretty clear consensus, I'm taking their advice as being a generally-accepted convention amongst git users. Granted, such conventions in git seem to be as ephemeral as branches (e.g., fads such as "rebase everything! rebase after every commit! No, wait, never rebase! Rebasing is evil! Nobody should rebase!"), but if you're trying to suggest that as a result there are no conventions, I'm just going to write you off.
  - hyperbolist 17y ago
    Conventions are just conventions anyway. We've established that there's no technical barrier to your two objections. 1) You can clone different branches into different paths, which is exactly like a traditional svn workflow, and a pretty normal thing to do for continuous integrations and the like. 2) And if you never want to delete a branch, you can check on their merged status to determine if they're "done". More clever solutions have been supplied by others in this thread. You needn't convert to git, but it'd be polite to recognize that your objection to git is purely psychological.